Ending the UX Designer Drought

The first article in this series, “A New Apprenticeship Architecture,” laid out a high-level framework for using the ancient model of apprenticeship to solve the modern problem of the UX talent drought. In this article, I get into details. Specifically, I discuss how to make the business case for apprenticeship and what to look for in potential apprentices. Let’s get started!

Defining the business value of apprenticeship

Apprenticeship is an investment. It requires an outlay of cash upfront for a return at a later date. Apprenticeship requires the support of budget-approving levels of your organization. For you to get that support, you need to clearly show its return by demonstrating how it addresses some of your organization’s pain points. What follows is a discussion of common pain points and how apprenticeship assuages them.

Hit growth targets

If your company is trying to grow but can’t find enough qualified people to do the work  that growth requires, that’s the sweet spot for apprenticeship. Apprenticeship allows you to make the designers you’re having trouble finding. This is going to be a temporal argument, so you need to come armed with measurements to make it. And you’ll need help from various leaders in your organization to get them.

  • UX team growth targets for the past 2-3 years (UX leadership)
  • Actual UX team growth for the past 2-3 years (UX leadership)
  • Average time required to identify and hire a UX designer (HR leadership)

Then you need to estimate how apprenticeship will improve these measurements. (Part 3 of this series, which will deal with the instructional design of apprenticeship, will offer details on how to make these estimates.)

  • How many designers per year can apprenticeship contribute?
  • How much time will be required from the design team to mentor apprentices?

Growth targets typically do not exist in a vacuum. You’ll likely need to combine this argument with one of the others.

Take advantage of more revenue opportunities

One of the financial implications of missing growth targets is not having enough staff to capitalize on all the revenue opportunities you have. For agencies, you might have to pass up good projects because your design team has a six-week lead time. For product companies, your release schedule might fall behind due to a UX bottleneck and push you behind your competition.

The data you need to make this argument differ depending on whether your company sells time (agency) or stuff (product company).

When doing the math about an apprenticeship program, agencies should consider:

  • What number of projects have been lost in the past year due to UX lead time? (Sales leadership should have this information.)
  • What is the estimated value of UX work on lost projects? (Sales leadership)
  • What is the estimated value of other (development, strategy, management, etc.) work on lost projects? (Sales leadership)

Then, contrast these numbers with some of the benefits of apprenticeship:

  • What is the estimated number of designers per year apprenticeship could contribute?
  • What is the estimated amount of work these “extra” designers would be able to contribute in both hours and cash?
  • What is the estimated profitability of junior designers (more) versus senior designers (less), assuming the same hourly rate?

Product companies should consider:

  • The ratio of innovative features versus “catch-up” features your competitors released last year. (Sales or marketing leadership should have this information.)
  • The ratio of innovative features versus “catch-up” features you released in the past year. (Sales or marketing leadership)
  • Any customer service and/or satisfaction metrics. (Customer service leadership)

Contrast this data with…

  • The estimated number of designers per year you could add through apprenticeship.
  • The estimated number of features they could’ve completed for release.
  • The estimated impact this would have on customer satisfaction.

Avoid high recruiting costs

Recruiting a mid- to senior-level UX designer typically means finding them and poaching them from somewhere else. This requires paying significant headhunting fees on top of the person-hours involved in reviewing resumes and portfolios and interviewing candidates. All the data you need to make this argument can come from UX leadership and HR.

  • Average cost per UX designer recruit
  • Average number of hours spent recruiting a UX designer

Contrast this data with:

  • Estimated cost per apprentice

To estimate this, factor in:

  • Overhead per employee
  • Salary (and benefits if the apprenticeship is long enough to qualify while still an apprentice)
  • Software and service licenses
  • Mentorship time from the current design team
  • Mentorship/management time from the designer leading the program

Increase designer engagement

This one is tricky because most places don’t measure engagement directly. Measuring engagement accurately requires professional quantitative research. However, there are some signs that can point to low engagement.

High turnover is the number one sign of low engagement. What kind of people are leaving—junior designers, seniors, or both? If possible, try to get exit interview data (as raw as possible) to develop hypotheses about how apprenticeship could help. Maybe junior designers don’t feel like their growth is supported… allowing them to leverage elements of an apprenticeship program for further professional development could fix that. Maybe senior designers are feeling burnt out. Consistent mentorship, like that required by apprenticeship, can be reinvigorating.

Other signs of low engagement include frequently missing deadlines, using more sick time, missing or being late to meetings, and more. Investigate any signs you see, validate any assumptions you might take on, and hypothesize about how apprenticeship can help address these issues.

Help others

If your organization is motivated by altruism, that is wonderful! At least one organization with an apprenticeship program actually tries very hard not to hire their apprentices. Boston’s Fresh Tilled Soil places their graduated apprentices with their clients, which creates a very strong relationship with those clients. Additionally, this helps them raise the caliber and capacity of the Boston metro area when it comes to UX design.

Hiring great UX apprentices

Hiring apprentices requires a different approach to evaluating candidates than hiring established UX designers. Most candidates will have little to no actual UX design skills, so you have to evaluate them for their potential to acquire and hone those skills. Additionally, not everyone learns effectively through apprenticeship. Identifying the traits of a good apprentice in candidates will help your program run smoothly.

Evaluating for skill potential

Portfolio. Even though you’re evaluating someone who may never have designed a user experience before, you still need them to bring some examples of something they’ve made. Without this, it’s impossible to get a sense of what kind of process they go through to make things. For example, one apprentice candidate brought in a print brochure she designed. Her description of how she designed it included identifying business goals, balancing competing stakeholder needs, working within constraints, and getting feedback along the way, all of which are relevant to the process of UX design.

Mindset. The number one thing you must identify in a candidate is whether they already possess the UX mindset, the point of view that things are designed better when they’re designed with people in mind. This is usually the light bulb that goes off in people’s heads when they discover UX design. If that light hasn’t gone off, UX might not be the right path for that person. Apprenticeship is too much of an investment to risk that. Evaluating for this is fairly simple. It usually comes out in the course of a conversation. If not, asking outright “What does user experience design mean to you” can be helpful. Pay careful attention to how people talk about how they’ve approached their work. Is it consistent with their stated philosophy? If not, that could be a red flag.

Intrinsic motivation. When people talk about having a “passion” for something, what that means is that they are intrinsically motivated to do that thing. This is pretty easy to evaluate for. What have they done to learn UX? Have they taken a class? That’s a positive sign. Have they identified and worked through a UX problem on their own? Even better! If a candidate hasn’t put in the effort to explore UX on their own, they are likely not motivated enough to do well in the field.

Self-education. While self-education is a sign of intrinsic motivation, it’s also important in its own right. Apprenticeship relies heavily on mentorship, but the responsibility for the direction and nature of that mentorship lies with the apprentice themselves. If someone is a self-educator, that’s a good predictor that they’ll be able to get the most out of mentorship. This is another fairly easy one to evaluate. Ask them to tell you about the most recent UX-related blog post or article they read. It doesn’t matter what it actually is, only whether they can quickly bring something to mind.

Professional skills. UX design is not a back-office field. UX designers talk with clients, customers, stakeholders, developers, and more. To be an effective UX designer a candidate must possess basic professional skills such as dressing appropriately and communicating well. Simple things like sending a “thank you” email are a great indication of good professional skills. (Physically mailed  thank you notes get extra bonus points. One-off letterpressed mailed thank you notes get even more!)

Collaboration. UX design is a collaborative discipline. If a candidate struggles with collaboration, they’ll struggle in the field. When discussing their work (especially class project work), be sure to ask what role they played on the project and how they interacted with other people. Complaining about others and taking on too much work themselves are some warning signs that could indicate that a candidate has trouble with collaboration.

Evaluating for apprenticeship fit

Learning pattern. Some people learn best by gradually being exposed to a topic. I call these people toe-dippers, as they prefer to dip their toes into something before diving in. Others prefer to barrel off the dock straight into the deep end and then struggle to the surface. I call these people deep-enders. While apprenticeship can be modified to work better for deep-enders, its gradual exposure can often frustrate them. It is much better suited for toe-dippers. Evaluating for this is tricky, though. Asking people whether they prefer to dive in or learn gradually, they’ll say “dive in” because they think that’s what you want to hear. Asking them how they’ve approached learning other skills can give some insight, but this is not 100% reliable.

Learning by doing. Apprenticeship helps people acquire skills through experiential learning. If this is not how a person learns, apprenticeship may not be for them. Evaluating for this is very much like evaluating for intrinsic motivation. Has someone gone to the trouble of identifying and solving a design problem themselves? Have they practiced UX methods they have learned about? If so, it’s likely that learning by doing is effective for them.

Receptiveness to critique. Apprenticeship is a period of sustained critique. Someone whose response to criticism is defensiveness or despondency will not be successful as an apprentice. This is easy to identify in an interview within the context of discussing the work examples the candidate has brought. My favorite technique for doing this is to find something insignificant to critique and then hammer on it. This is not how I normally critique, of course; it’s a pressure test. If a candidate responds with openness and a desire to learn from this encounter, that’s a very positive sign. If they launch into a monologue defending their decisions, the interview is pretty much over.

If you’re fired up about UX apprenticeship (and how could you not be?), start making it happen in your organization! Do the research, find the data, and share your vision with your company’s leadership so they can see it too! When you get the go-ahead, you’ll be all ready to start looking for apprentices. If you follow these guidelines, you’ll get great apprentices who will grow into great designers. Stay tuned for Part 3 of this series where I’ll get detailed about the instructional design of apprenticeship, pedagogy, mentorship, and tracking!

Ending the UX Designer Drought

The user experience design field is booming. We’re making an impact, our community is vibrant, and everyone has a job. And that’s the problem. A quick search for “user experience” on indeed.com reveals over 5,000 jobs posted in the last 15 days (as of March 15, 2014) in the United States alone! Simple math turns that into the staggering statistic of 10,000 new UX-related jobs being created every month.

This amount of work going undone is going to prevent us from delivering the value that UX promises. It’s going to force businesses to look toward something more achievable to provide that value. For user experience design to remain the vibrant, innovation-driving field it is today, we need to make enough designers to fill these positions.

Fortunately, there are a tremendous number of people interested in becoming a UX designer. Unfortunately, it is nearly impossible for these people to land one of these jobs. That’s because of the experience gap. All these UX jobs are all for people with 2-3 years of experience–or more.

UX design is a strategic discipline in which practitioners make recommendations that can have a big impact on an organization’s revenue. Frankly, a designer isn’t qualified to make these kinds of recommendations without putting in some time doing fundamental, in-the-trenches research and design work. While this might seem like an intractable problem, the skills required to do this fundamental work can be learned!

Someone just has to teach them.

Solving the problem

There are many ways to to teach fundamental UX design skills. Design schools have been doing it for years (and the new, practically-focused Unicorn Institute will start doing it soon). However, to access the full breadth of people interested in UX design, education in UX design needs to be accessible to people at any stage of their lives. To do that, you need to make learning a job.

This is not as crazy as it sounds. Other professions have been doing this for hundreds of years in the form of apprenticeship. This model has a lot to offer the UX design field and can be adapted to meet our particular needs.

What is apprenticeship?

In the traditional model of apprenticeship, an unskilled laborer offers their labor to a master craftsman in exchange for room, board, and instruction in the master’s craft. At the end of a certain period of time, the laborer becomes a journeyman and is qualified to be employed in other workshops. To be considered a master and have their own workshop and apprentices, however, a journeyman must refine their craft until the guild determines that their skill warrants it.

While this sounds medieval–because it is–there are a few key points that are still relevant today.

First, apprenticeship is learning by observation and practice. Designing a user experience requires skills that require practice to acquire. Apprentices are also compensated with more than just the training they receive. Even “unskilled,” they can still provide value. A baker’s apprentice can haul sacks of flour; a UX apprentice can tame the detritus of a design workshop.
Apprenticeship is also limited to a specific duration, after which the apprentice is capable of the basics of the craft. In modern terms, apprenticeship is capable of producing junior designers who can bring fundamental, tactical value to their teams. After a few years of practicing and refining these skills, those designers will be qualified to provide the strategic UX guidance that is so sought after in the marketplace.

A new architecture for UX apprenticeship

The apprenticeship model sounds good in theory, but does it work in practice? Yes. in 2013, The Nerdery, an interactive design and development shop in Minneapolis, ran two twelve-week cohorts of four apprentices each. There are now eight more UX designers in the world. Eight designers might seem like a drop in the 10,000-jobs-per-month bucket, but if more design teams build apprenticeship programs it will fill up very quickly.

Building an apprenticeship program might sound difficult to you. However, The Nerdery’s program was designed in such a way that it could be adapted to fit different companies of different sizes. We call this our UX Apprenticeship Architecture, and I encourage you to use it as the basis of your own apprenticeship program.

There are five components to this architecture. Addressing each of these components in a way that is appropriate for your particular organization will lead to the success of your program. This article only introduces each of these components. Further articles will discuss them in detail.

Define business value

The very first step in building any UX apprenticeship program is to define how the program will benefit your organization. Apprenticeship requires an investment of money, time, and resources, and you need to be able to articulate what value your organization can expect in return for that investment.

Exactly what this value is depends on your organization. For The Nerdery, the value is financial. We train our apprentices for them to become full members of our design team. Apprenticeship allows us to achieve our growth goals (and the revenue increase that accompanies growth for a client services organization). For other organizations, the value might be less tangible and direct.

Hire for traits, not talent

Once you’ve demonstrated the value of apprenticeship to your organization and you’ve got their support, the next thing to focus on is hiring.

It can take a long time at first until you narrow down what you’re looking for. Hiring apprentices is much different from hiring mid to senior level UX designers. You’re not looking for people who are already fantastic designers; you’re looking for people who have the potential to become fantastic designers. Identifying this potential is a matter of identifying certain specific traits within your applicants.

There are two general sets of traits to look for, traits common to good UX designers and traits that indicate someone will be a good apprentice. For example, someone who is defensive and standoffish in the face of critical feedback will not make a good apprentice. In addition to these two sets of traits, there will very likely be an additional set that is particular to your organization. At The Nerdery, we cultivate our culture very carefully, so it’s critical for us that the apprentices we hire fit our culture well.


“Pedagogy” means a system of teaching. Developing the tactics for teaching UX design can take time as well, so it’s best to begin focusing on that once recruiting is underway. At The Nerdery, we found that there are four pedagogical components to learning UX design: orientation, observation, practice, and play.

Orientation refers to exposing apprentices to design methods and teaching them the very basics. In observation, apprentices watch experienced designers apply these methods and have the opportunity to ask them about what they did. Once an apprentice learns a method and observes it in use, they are ready to practice it by doing the method themselves on a real project. The final component of our pedagogy is play. Although practice allows apprentices to get a handle on the basics of a method, playing with that method in a safe environment allows them to make the method their own.


Observation and practice comprise the bulk of an apprentice’s experience. Both of these activities rely on close mentorship to be successful. Mentorship is the engine that makes apprenticeship go.

Although mentorship is the most critical component of apprenticeship, it’s also the most time-intensive. This is the biggest barrier an organization must overcome to implement an apprenticeship program. At The Nerdery, we’ve accomplished this by spreading the burden of mentorship across the entire 40-person design team rather than placing it full-time on the shoulders of four designers. Other teams can do this too, though the structure would be different for both smaller and larger teams.


The final component of our apprenticeship architecture is tracking. It is largely tracking apprentice progress that gives apprenticeship the rigor that differentiates it from other forms of on-the-job training. We track not only the hours an apprentice spends on a given method but qualitative feedback from their mentors on their performance. Critical feedback is key to apprentice progress.

We track other things as well, such as feedback about mentors, feedback about the program, and the apprentice’s thoughts and feelings about the program. Tracking allows the program to be flexible, nimble, and responsive to the evolving needs of the apprentices.

Business value, traits, pedagogy, mentorship, and tracking: Think about these five things in relation to your organization to build your own custom apprenticeship program. Although this article has only scratched the surface of each, subsequent articles will go into details.
Part two of this series will cover laying the foundation for apprenticeship, defining its business value and identifying who to hire.

Part three will focus on the instructional design of apprenticeship, pedagogy, mentorship, and tracking.

If you’ve got a design team and you need to grow it, apprenticeship can help you make that happen!

Your Boss Works for You

This past June, I stood on the brink of achieving a major professional goal. The UX apprenticeship program I’d been working so hard on was going to begin on Monday. It was Thursday. On my desk lay a curious stack of paper labeled “Manager’s Onboarding Kit.”

Of all the things I’d planned for and anticipated about the apprenticeship program, becoming a manager was something I hadn’t even considered. It’s something I’ve consciously avoided my entire career. The apprentices arrived, and I awkwardly mentioned that “technically” I was their manager. But after working with them for awhile I noticed something that changed my whole perspective.

I was working for them, and I loved it!

Granted, my situation might be unique in that my express purpose is to nurture and grow the apprentices’ nascent skills, but I learned many lessons about management that other managers can benefit from. Each of these lessons revolved around ways in which I found myself working for my team.

I cleared the path

Long ago, Samantha Bailey told me that the role of a UX manager is to shield her team from the chaos above them. I’m glad that lesson has stayed with me for so long, because I was able to put it into practice with the apprentices. I told them that their primary goal was to learn new skills and grow them. If anything got in the way of that, they should come to me and I would make whatever it was go away. I helped them clear a path to their goal through the organizational jungle.

An unexpected but happy consequence of this was that my working hard for my team inspired them to work hard for me. If you work for a consultancy or agency, you’re probably required to fill out your timesheet daily. And you probably don’t do it. The apprentices did. I told them that I relied on their time entries to track their progress and needed them to enter their time, daily, and never once did I have to have the timesheet talk with any of them.

I told it like it was

I wasn’t born in Minnesota, but I may as well have been. I am rife with Minnesota Nice. Giving people feedback beyond, “Great job! Here’s some hotdish!” makes me twitchy. But my role is to help people with promise develop that promise into talent. To do this, I needed to extend myself beyond my comfort zone and give the apprentices feedback about things they needed to work on.

It wasn’t easy for me, but it did get easier as time went on. This was because my telling it like it was led them to trust me. That trust yielded results. One apprentice in particular would make a point of implementing the feedback I gave her. One week I’d awkwardly say she should work on something, and then the next week I’d both hear feedback from mentors about how she’d done that thing and she would tell me herself. That not only helped her grow; it helped me grow too.

I increased my say/do ratio

One of my early mentors kept track of her “say/do ratio” on the whiteboard at her desk. This is a personal metric that describes how reliably a person does what they say they’re going to do. I laughed, but she was serious about it. She was exceptionally reliable. I’m fortunate that this is another early lesson I retained.

When you work for your team, you need to do a lot of things for them. I’ve not always been the most organized person, but I felt was important enough to commit to making a concentrated effort. Working for my team would be no good if I didn’t do the things they needed me to do.

Being an interaction designer, naturally I designed a process to keep track of what I said I was going to do and whether I had done it. Often, apprentices would come up to me as I was at my desk. A to-do would often come out of that conversation. I use Things to track my tasks, and I keep it open at all times. With a simple key combination I could instantly enter a new task, leaving for later the classification of the new task. During our weekly one-on-one meetings, I left a section in the Evernote note that guided each meeting for me to keep track of new things an apprentice would need me to do. Each item had a checkbox, and after the meetings I’d enter them into Things and check off the boxes in Evernote. Once the item was completed, I’d check it off in Things. Maybe this seems excessive to you, but it works for me. Find whatever works for you and do it consistently.

I constantly sought feedback

At the very beginning of the program I let my team know that I had neither managed anyone before nor run an apprenticeship program. I told them I needed them to provide feedback on both me and the program for it to be as good as it could be. Sometimes they’d provide me with feedback I wouldn’t implement, but when that happened I explained why. Sometimes the things they needed me to do for them would take awhile. Sometimes the solutions to the problems they brought up weren’t obvious.

In these situations, I communicated with them about what was happening and I sought feedback on my proposed solutions. I consciously showed them that by giving me feedback they could make things happen. As it turns out, the apprentices and I improved the program together.

My favorite example of how we built the program together is the internal project they all worked on as a team. Initially, I was dead set against apprentices working on internal projects. To me, internal projects were something to keep interns busy. I felt that internal projects would be a waste of time for apprentices. The goal of apprenticeship is to learn UX design through actual client work.

The apprentices were getting that experience, one design method at a time. They’d do stakeholder interviews on one project, then user research analysis on another. What they weren’t getting was a look at how the design process moved from one stage to another, say from research to analysis and then design. After they brought this up enough times, I swallowed my pride and suggested they work on an internal project together, from start to finish, with me as their mentor. They jumped at the chance, did a stellar job, and learned what they’d set out to learn.

I was there

The act of being physically present with your team shows that you support them. I chose to sit right in the middle of mine. Not at one end of the desks, not in an office, but right in the middle of the apprentice team. We have an open floor plan at The Nerdery, where people sit in groups of 6-8 desks rather than in individual cubicles. Being right in the middle of my team made me easier to talk to because I was only a glance away from any of them. The result was that the apprentices talked to me a lot and used the support I offered.

I ran the numbers, but I didn’t let the numbers run me

Running an apprenticeship program for four apprentices takes a lot of tracking. I have to track their time, feedback on them, and feedback they’re giving me. I also have to track how much the program is costing and whether it’s hitting its metrics. If it’s not, I have to do things to move the numbers up. Yes, this takes time. But I did these tasks early in the morning before the apprentices arrived. When they did, I could focus on them.

With management comes administration, but administration is not the essence of your job. Your job is to clear the way for your team, and administration is just another thing you’re clearing from their path. Yes, it’s something you have to do, but it should absolutely not be your focus. Your team is your focus.

Problems I faced

Even though I felt exhilarated and energized by my new role as a manager, it wasn’t all rainbows and unicorns. For example, I was still on a project as a billable designer. Balancing the work I wanted to do for my team with the work I needed to do for my client was challenging. Sometimes, I just wanted to hide so I could focus on data analysis or sketching, but I resisted. When you’re physically present, you should expect to be interrupted. What’s helpful, though, is to remember that they’re not really interruptions; they’re your job. The really tricky thing is that you can’t ever predict your team’s needs, so always expect the unexpected and have someone who can support you.

My own managers and my project team were my supports. One manager had a knack for giving me feedback without pussyfooting around. I appreciated that in her and I tried to emulate it myself. When I talked with her about becoming a manager, she let me in on a secret. She was like that with me because that’s what I responded well to. Other people needed pussyfooting to accept feedback.

When I confessed my newly positive feelings about managing to my other manager, he beamed with a knowing smile. At that moment, I knew that he’d been working for me and everyone else all along. Now when we meet, he encourages me to keep working for the apprentices and he helps me break down any organizational barriers that arise.

My project team supported me by respecting the fact that I now had two jobs. When they needed my undivided attention, they scheduled collaborative work time with me. This helped me balance my client and management responsibilities. They didn’t schedule all my unscheduled time, just some of it. This allowed me to focus on the client for a time without being out of reach. I simply told the apprentices where I’d be.

What you can take away from this

If you are determined to avoid management at all costs, like I was, here’s what I want you to take away. Managing people doesn’t have to suck. It doesn’t have the obvious allure of design, solving problems and making things, but if you approach management as if it were a design problem, it can be incredibly rewarding. Think of your team as your users and their ability to achieve their goals as their experience. Good management is the continual, real-time design of your team’s experience. When you get the opportunity to manage people, take it. Don’t run away from it.

If you are already managing people, try putting some of these lessons I’ve learned into your own management practice. It will make your work more fulfilling. If you are already working for your team, that’s wonderful! Let’s hear what you’ve learned about it!


Learn More from our Archives

Erin Malone’s So You Think You Want to be a Manager

Christina Wodtke’s Career Choices for Designers

Brenda Janish’s Leading from Within

Integrating Prototyping Into Your Design Process

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you.

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

version w/ arrows

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

bottom left Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

  • Does the system have all the features required to support the user’s goals?
  • Does the workflow make sense at a high level?
  • Which UX concept works best?
  • Coming to consensus on a UX concept with stakeholders, e.g.“Is this what you meant?”

bottom right Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

  • Evaluating the usability of proposed designs for new systems
  • Exploring isolated interactions as a proof-of-concept
  • Validating UX design direction with stakeholders
  • Validating the implementation of requirements with stakeholders
  • Supplementing printed documentation for development teams
  • Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth.

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

top left High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

top right High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

  • Evaluating the usability of proposed UX designs for an existing system
  • Performing usability tests with non-savvy user groups
  • Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

People like shiny things that move. The cool factor of prototyping will be difficult to resist.

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

  • Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
  • High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

  • High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
  • These prototypes should also be used for user testing, if at all possible.
  • Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.


When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

  • Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
  • Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
  • Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
  • Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.