How to make UX more visible: the power of the medium-fidelity design
How medium fidelity designs help you beyond just user testing
One of the trickiest things to figure out when you join a new company is understanding what different UX terms mean to them. Recently, I had to navigate the trickiness of the term "Medium Fidelity" when it came to prototypes.
Of course, I knew their textbook definition, but these were use cases that meant different things to different stakeholders. As it turns out, this was a way to make UX more visible across the entire organization, but I needed to account for different requirements to have 3 slightly different design prototypes to match.
Learning to decipher this ask required me to understand the different groups asking to see "Medium-fidelity" designs and what they wanted from them.
Understanding the purpose of medium-fidelity prototypes
Medium fidelity prototypes are tricky to describe, but not for the reason you might think. Instead, the reason is that they're the most common prototype you design, and you could show a wide range of things.
The textbook definition of a medium-fidelity prototype is one with limited functionality but clickable areas that present interactions and navigation possibilities of an application.
That definition is acceptable enough if you're applying medium-fidelity prototypes to users. Whether it's user interviews, testing, or more, these designs work well for getting user feedback.
But sometimes, stakeholders ask you for a Medium-fidelity design outside of user testing. These are opportunities to make UX more visible across the whole organization, but this opportunity also comes with a unique set of challenges.
For example, what should happen with the elements of the page that aren't hooked up yet? Do they exist in an incomplete state? Do they link somewhere? Not to mention, sometimes innocuous wording that you use in a Medium-fidelity design can lead to many off-topic discussions.
I'll offer clarity based on my experiences. In general, Medium-fidelity designs that stakeholders want are focused around one major thing: a 'complete' user flow and clickable prototype. So even if some pages are placeholders, navigating through the typical flow and tasks is often the most crucial thing.
This is because of three things:
Medium-fidelity prototypes are about asking questions and getting answers
You're often not there to explain the complete Design (or showcase features if the user gets stuck)
People are more interested in how things fit together than in the Design at this stage.
Whether it's a Figma flow or an Axure file, robust navigation is one of the essential things about Medium-fidelity prototypes.
But while this helps us get started with Medium-Fidelity prototypes, that doesn't tell us everything we need about what to include. To do that, you must consider the type of person asking you for this medium-fidelity prototype.
The three types of stakeholders when it comes to medium-fidelity prototypes
While this is not a comprehensive list, I've found that there tend to be three significant categories of stakeholder that ask for this deliverable:
Engineers with exact blueprints
Product/Executives with Future Vision
UX Managers that need to sell your design ideas
Here's what they often want.
The hyper-focused Engineer who wants exact blueprints
This archetype tends to exist on the Engineering team (and people that come from this background). In my experience, they ask for the Medium-fidelity prototype to address one of two needs:
The ability to 'look forward': see what they're building now and what they'll build next sprint.
The ability to estimate work: if a designer builds something and the Product Manager approves it, how much work will they need to put in (on the back end)
As a result, these people want as exact specifications as you can provide them. To them, medium fidelity is how it will look like exactly, minus the 'nice coat of paint.'
This is not necessarily the best mindset, but this is often a cultural issue that can be hard to crack as a Designer. However, I've worked with enough teams like this to know that one of the best ways to manage they expect to understand the time pressure that they're under.
Engineering teams are often expected to build quickly, whether in "Product-Led Growth," startup environments, or more. As a result, they often want one "source of truth" for what they build, and it can either come up down to one of two places:
An internal wiki/JIRA board/user story with the requirements spelled out
A design prototype with all of the above things factored into it
If Designers are expected to design to the specifications (and they do), then the more straightforward thing for engineers is to look at the prototype, see what's on there, and build precisely to that blueprint. So what do you do if that's the case?
Organize design pages by a sprint (and use Master Components)
I often organize my pages by sprint for these teams. For example, one sprint might have a simplified home page with disabled buttons (or no buttons), while the next sprint would have a home page with more details and paths to take.
To do this, I work extensively with Master Components and Variants in Figma. First, I build a particular Component to match the level of work Engineering needs and usually leave that on the page.
Then, next sprint, when things get more detailed, I copy that Component over to a new page, think about how I want to update it, and then make another Master Component for the new page to ensure that everything remains consistent across everything.
This is a little tedious to maintain, but when you're working with the Engineering team on a time crunch, this is a decent alternative rather than having them interpret your Design. However, that's not the only audience that might need to see medium-fidelity prototypes.
The future-looking Product teams with a complete workflow
This scenario was something that I encountered recently, which got me to change my process around Medium-fidelity prototypes.
In this example, the Product team wanted to make our medium-fidelity prototype available to the entire organization by putting it on our internal wiki and sending a link to various stakeholders. The purpose was to have one link people could refer to see what UX was doing (and the progress we were making at the time).
You might think this would involve the same steps as the Engineering team (highly polished pages with limited features), but some Product teams don't like that approach. Instead, what they want to showcase is the complete user flow, from start to finish, even if some pages are screenshots or placeholders.
Rather than saying, "This is the work we have right now, built by Engineering," they often want to say, "These Designs were just approved by the Product Team, which is 2–3 sprints ahead, so it's coming soon."
Things in this prototype might change as more and more features are fleshed out and designed, incentivizing stakeholders to check in occasionally. In this case, we need to have the mindset of a "Master Copy."
Provide a clickable master link where everything that approved lives
The most important thing for these stakeholders is to have one static "Master Copy" prototype link that should always work. As soon as new designs or ideas are approved, they often should be moved here and double-checked so that all interactions work on the page.
In addition, this "Master Copy" page should have the most robust navigation, including browser back buttons, navigation shortcuts, or "restart the prototype" buttons. We include these features to help avoid one painful conversation: the "emergency call."
Sometimes, your Product team will talk with other people about something unrelated, and they want to show off your work (or ask a question). You're not part of these meetings and probably shouldn't be.
So the Product team goes to the link they bookmarked, and suddenly something breaks (or it's not hooked up correctly). Suddenly, you get messaged out of nowhere, asking for the "correct link" on the page, and you essentially have to drop everything to fix it (which is often problematic).
To avoid this, ensure that all interactions are hooked up ahead of time correctly on this page. It doesn't matter if some pages are blank placeholders, make sure that as you update this medium-fidelity prototype, it's always working, accessible, and nothing breaks.
However, there's a 3rd type of stakeholder that I recently came across where things get a little fuzzier. Again, these are often just as important as the previous two stakeholders, but they're for slightly different purpose.
Your UX manager, who talks with executives
Lastly, I've only recently encountered this situation, which led to much internal discussion with our UX team. Sometimes, your manager will ask for a Medium-fidelity prototype which they can take to other higher-ups to sell your ideas, ask essential questions, and more.
For example, maybe your UX Manager has a standing meeting with the CEO (or other executives) where they give updates, present your ideas, or ask questions.
If you're a Junior UX designer, there's a great temptation to make everything as polished as possible. However, it might not be in your best interest to create something that looks high-fidelity: part of the reason for this is that there are still unfinished questions that you might have.
If your prototype looks mostly done, the executives might push you to move on to the next step when you're not ready. But, simultaneously, you don't want something so sloppy that executives wonder what UX is doing.
So what should the Medium-fidelity prototype look like in this case? It took me a long time to figure out how to answer this, but I found a suitable answer. The answer should be centered on what you want that conversation (between your manager and the executive) to be about.
For example, suppose the executive seeing this prototype knows all about Data, Analytics, and more. In that case, it's more productive to have him ask questions (and vice versa) about the Data you're presenting or possible solutions rather than commenting that the color sucks or it's incomplete.
So while it's essential to have robust navigation, keyboard shortcuts, and more, the conversation should be about what you don't know about the product. Here are some ways to do that.
Include external stickies or other things to ask questions:
This is the most basic way to ask questions but has limited use. Instead, include something that does not look like it belongs in the Design, such as a yellow sticky note with dotted lines around it, to ask questions about it.
Put that in the prototype, and have them presented to get direct feedback about one thing in particular. Part of the problem with this approach is that you have to use it sparingly: she had too many sticky notes, and people can't see your Design.
However, if there are one or two burning questions about a page that will help in Design, this is the simplest thing to do.
Provide dummy sample data on the page:
Another thing that you can do is provide sample data for them to comment on. For example, some readers might know that I don't like lorem ipsum because it's a wasted opportunity to get your stakeholders to comment on the text.
However, that doesn't always apply to any text: sometimes, you're unsure what data needs to be displayed in tables, lists, cards, and more. If that's the case, provide the best data you can, even if it's not 100% correct. It's not wrong to be slightly incorrect about the data because conversations about it can be productive. That also opens up the question of what should go there or what we want to show.
Use limited navigation or features with dead ends as conversation starters:
Depending on which of the two camps the executives your manager is presenting to fall into, you either want to restrict certain features to be non-clickable or have it lead to the example of a work in progress page. If you don't know the requirements, you could use a sticky note I mentioned above to write out what you know, but otherwise, it's good to have that so that your manager can ask about it.
If the stakeholder sees that, they might have comments on it or other things to contribute. Either way, whatever you will hook up together for the medium fidelity prototype, there's one thing you should forget: test with your audience.
Refine your medium-fidelity prototype with feedback
Whether it's your manager requesting this or your Product team, the most important thing to remember is to request feedback. Of course, you won't get it 100% right on the first try, but presenting your thoughts and ideas like this helps to get productive feedback.
Depending on the size of the project, a Medium-fidelity prototype might only exist for a few weeks or as long as a few years. As a result, this prototype might be what your team refers to all the time rather than using the old Design.
So it's good to ensure you know how to build and maintain a medium-fidelity prototype for a large chunk of your product. This way, if new stakeholders come on board, team members have questions, or you want to showcase UX's work, there's one place they can turn to (even if it's for different purposes).
So next time you move past low-fidelity prototypes, don't worry about whether things need to be pixel-perfect or what needs to be shown. Instead, consider the people asking you for the medium-fidelity prototype and what they want.
Want to become a UX professional? I’ve written a free e-book explaining how to make yourself an ideal UX candidate.
Kai Wong is a Senior Product Designer and a top Design Writer on Medium. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.