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

Ask UXmatters

Get expert answers

A column by Janet M. Six
August 17, 2020

This month in Ask UXmatters, our expert panel is continuing our conversation about when and why to use low-fidelity or high-fidelity prototypes. One of our UX expert explores the need to truly understand all of the dimensions that affect the creation of design artifacts, including resource constraints, the stage of the product-development lifecycle, what desired project outcome is driving the need to create a prototype, and the context in which the design project exists.

Plus, another one of our UX experts discusses how the quality of a product team’s communications can affect your choices about what types of prototypes to create. Finally, another of our experts considers the need to iteratively create different types of prototypes depending on their purpose, which can evolve over the different stages of the product-development cycle.

You might also want to read Part 1 of this column, in “Creating Low-Fidelity or High-Fidelity Prototypes, Part 1.”

Champion Advertisement
Continue Reading…

Every month in Ask UXmatters, our panel of UX experts answers readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].

  • Michael Bengwayan—UX Designer at Saggezza
  • Leo Frishberg—Director of User Experience at athenahealth, and Principal at Phase II
  • Andrew Wirtanen—Lead Designer at Citrix

Q: What factors do you consider in choosing whether to provide low-fidelity or high-fidelity design deliverables?—from a UXmatters reader

“The reader’s question speaks to just one of the dimensions of choosing what design artifacts to create—fidelity—but crafting such artifacts involves a varied set of dimensions, each having different possible ranges,” replies Leo. “Here are a few dimensions of this decision to consider:

  • resource constraints—How much time and energy and what level of competency does the team have to invest in creating the artifact?
  • stage in the product-development lifecycle (PDLC)—What is the purpose for which the team is crafting the prototype? For example, you might want to create a prototype to explore
    • the leadership team’s beliefs about the market
    • the product-management team’s beliefs about the problem
    • the design team’s understanding about a specific user flow
    • the possible solutions to a given problem
  • project outcomes—What outcomes should the design artifact drive?
    • collecting data in service of the goals of the various stages in the PDLC
    • proving a technical concept for the engineering team
    • thinking to enable the UX team to better understand their own designs
  • context and tools—What is the context of the project? What tools are at the team's disposal?
    • Is a team or just one person responsible for building the artifact?
    • Is the team remote or collocated with the intended audience?
    • Is the project an asynchronous or synchronous engagement?
    • Is the team using digital or analog tools?

“Crafting a design artifact is a mini-design problem in itself. Considering fidelity addresses just one of dozens of challenges.”

“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.” 

Product Manager at Tom Sawyer Software

Dallas/Fort Worth, Texas, USA

Janet M. SixDr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research.  Read More

Other Columns by Janet M. Six

Other Articles on Deliverables

New on UXmatters