Creating Low-Fidelity or High-Fidelity Prototypes, Part 2

“Taking all of these factors into account, but looking through only a fidelity lens, I’ll offer some of my own rules of thumb,” continues Leo.

• In the early stages of the PDLC, I rely on using found objects to drive conversations in which artifacts play a role. These could be artifacts that members of the audience bring to our attention—for example, a specific Web site, a specific page in a manual, or a particularly important sticky note on a user’s monitor. Found-object artifacts could be of any fidelity.
• When we’re in the early stages of the PDLC and the team is trying to validate their understanding of the market, the problem space, or the strategy, I can rely on any artifact that represents the team’s assumptions regarding the audience—to enable us to understand where we got it wrong. Depending on these variables, the artifact could be a diagram or model of our understanding, a sketch of a future state, a brief science-fiction story, a context scenario, or maybe a skit or concept video. The key here is to identify profitable, pervasive problems, not solutions.
• When the team is certain they have identified the right problem—by definition, that happens much later in the PDLC—I might create storyboards that represent the proposed solution before putting any pixels into place.
• Eventually, when I’m crafting design candidates, I choose a few to offer to internal and external stakeholders. In this case, I craft as high a fidelity artifact as necessary to answer key questions such as the following: Is this technically feasible? Does this actually address the problem we agreed we need to solve? Does this meet brand and organizational messaging requirements? Do we understand it well enough to build it? Would you be proud to demo this solution?

“So, fidelity is not the target, but just another ingredient that we consider when crafting a design artifact to serve our purposes.”

The Role of Team Communication

“High-fidelity prototypes are particularly helpful when communication barriers exist between the design team and the rest of the project team,” answers Andrew. “For example, your engineering team might be in a distant time zone, which requires asynchronous communication. In Adam Polanksy’s talk, ‘The Importance of Presentation Value in UX Deliverables,’ he refers to the byproducts of communication barriers as signal loss. To compensate for signal loss, you need to create higher-fidelity deliverables. Otherwise, you risk engineers’ misinterpreting your designs or making critical design decisions without the UX design team’s involvement.

“When a UX designer has a close working relationship with the entire product team, lower-fidelity designs could suffice because there is clarity and ease of communication. Instead of creating a design prototype, the team might be able to work more quickly and collaboratively to code a real prototype. The product team can integrate many perspectives and ideas early in the design process.

“The project’s situation and goals dictate the necessary level of fidelity. In most cases, UX designers would prefer working in lower fidelity, with a close team and good cross-disciplinary communication, rather than creating high-fidelity prototypes. Specifying every little detail in a pixel-perfect, high-fidelity prototype can be a painstaking process. A product team’s working in close collaboration usually results in their building a higher-quality product, in less time overall.”

Creating Prototypes Iteratively

“I’ll try to answer this question as objectively as possible,” responds Michael. “My answer: No designer should have a general preference for low-fidelity or high-fidelity prototyping. The output should depend on the end goal, not on the method.

“Depending on the purpose and the process of prototyping, starting with a low-detail, low-fidelity prototype is usually the way to begin. The purpose of creating a prototype is to build an experimental model of an idea. Todd Hausman, a UX researcher at Google, says that it’s a way to give an idea a presence. A prototype of a design should be quick and easy to make and remake, so you won’t feel bad when it gets rejected—I mean, when it needs revisions. Once you nail the business requirements with your low-fidelity prototype, you can polish it into a high-fidelity prototype.

“However, to be honest with you, I prefer creating high-fidelity prototypes at work. I’m not messing with you. Let me explain. As you continue designing awesome applications for humanity, you can’t keep starting from scratch. It is good practice to create a Front-End Style Guide—that is, to standardize and make templates of your user-interface (UI) components, microcopy, colors, and type. Then you won’t have to start from scratch all the time. You can just pull out a page template, tweak it a bit, and voilà!

“Again, the goal of a prototype is to give an idea a presence. So, if you’re able to do that by using high-fidelity elements that are readily available, you’re good to go.”