Redesign Democracy: Dare to Think Big

Written by: Dirk Knemeyer

Why are you in UX? It probably isn’t to get rich. Yes, there is plenty of money in being a UX professional today. If you’re competent, you should be enjoying a very nice lifestyle. But we do this not for money–being on the business side would be far better at achieving that goal. We do it for creative reasons, expressive reasons, quality of life reasons, perhaps even altruistic reasons.

Yet, despite the broader motivations we share for choosing our vocation, we are rarely the community that spawns big ideas. It is more likely to be the capitalist, the marketer, or even the philosopher. But, why? I’ve lived in these communities, too–a dot-com CEO for a few years, an advertising executive for a few years, working in university to a philosophy Ph.D.–and I can tell you the paragons of those communities are no smarter than the paragons of our own. Yes, they may have more ambition and audacity and expectation of being big, but they are no better suited to develop big ideas or make radical change in the world than we are. I say this as someone who has been in all of these worlds and continues to choose to associate with the UX community as opposed to the others.

As a group, we are creative. We are open-minded. We try to create solutions that solve problems in the best possible way, and we do so for people. Practical solutions. Ideas based in real-world application and context. As the U.S. Congress has a historically low approval rate, as Antarctica melts into the oceans, as ISIS beheads innocents, and Russia maneuvers to swallow up the Ukraine, we need better solutions.

Why not us? I would argue we are uniquely able to provide the critical solutions to move humanity forward, solutions that synthesize technology with a concern for and understanding of the human condition.

However, user experience is typically focused on the “things” within the world. Yes, sure, with a focus on how people interrelate with those things but even when we are looking at “ecosystems” of experiences, they generally relate to ideas, structures, and systems that other people have imagined. We may deliver the existing idea in a better way, but it is not something that spawned from our mind.

Like many people in the United States, I have become increasingly disenchanted with our political system. As our population grows our legislature does not keep pace, meaning that each of us are farther and farther removed from the decisions being made for us in the Federal government. Ours is supposed to be a government of self-representation, but our dwindling connection to those decision makers only reinforces a plutocracy–a government for the wealthy–where she who has the most money, wins. The Congressional approval rate is now under 10%, a stunning indictment on the current system. This is happening against a backdrop where personal computing technologies are removing the old barriers that required an abstracted form of representational government in the first place. The situation is simply begging for a change.

This week I released my proposal to Redesign Democracy.

It is audacious in its charter and sure to be squashed by people who have significant monetary incentive to keep the current, crooked, hopelessly out-of-date model in place. But frankly, my friends, I don’t give a damn. I want to make the world better. I will make the world better, and these ideas will be some part of that in ways small or larger. You can develop solutions that make the world better, too. You just need to think bigger, take on some of those challenges, and have the courage to throw it out there into and against systems that will surely resist it.

Let’s stop tolerating the things that suck. We are explorers, creators, change makers. We don’t need Ph.D.s or splashy titles or high profit companies to make the world better; we just need to build the damn things.

I published Redesign Democracy in an honest effort to propose a better path that could actually be implemented and make the world much better. But there is a second reason:

I want to inspire you to create even better things. To dare. To dream. To put it all out there, whatever.

The worst thing you do is get a few people to think differently. The best? If your idea is good, and your timing is right, and you get a little lucky, you just might change the whole, entire, wonderful world that we share with over seven billion others.

What about the world would you like to see changed, and how might we be a catalyst to change it? Please share your ideas in the comments, below.

Five Things They Didn’t Teach Me in School About Being a User Researcher

Written by: Chelsey Glasson

Graduate school taught me the basics of conducting user research, but it taught me little about what it’s like working as a user researcher in the wild. I don’t blame my school for this. There’s little publicly-available career information for user researchers, in large part because companies are still experimenting with how to best make use of our talents.

That said, in the midst of companies experimenting with how to maximize user researchers, there are a few things I’ve learned specific to the role of user researcher that have held true across the diverse companies I’ve worked for. Some of these learnings were a bit of a surprise early on my my career, and I hope in sharing them I’ll save a few from making career mistakes I made in the past for lack of knowing better.

There’s a ton of variation in what user researchers do.

In my career, I’ve encountered user researchers with drastically varying roles and skillsets: many who focus solely on usability, a few who act as hybrid designers and researchers, some that are specialists in ethnography, and yet others who are experts in quantitative research. I’ve also spoken with a few who are hybrid market/user researchers, and I know of one tech company that is training user researchers to own certain product management responsibilities.

If you take a moment to write down all of the titles you’ve encountered for people who do user research work, my guess is that it will be a long one. My list includes user experience researcher, product researcher, design researcher, consumer insights analyst, qualitative researcher, quantitative researcher, usability analyst, ethnographer, data scientist, and customer experience researcher. Sometimes companies choose one title over another for specific reasons, but most of the time they’ll use a title simply because of tradition, politics, or lack of knowing the difference.

At one company I once worked for, my title was user researcher, but I was really a usability analyst, spending 80% of my time conducting rapid iterative testing and evaluation (RITE) studies. When I accepted the job at that company, I assumed–based on my title–that I’d be involved in iterative research and more strategic, exploratory work. I quickly learned that the title was misleading and should have been usability analyst.

What does this all mean for your career?

For starters, it means you should do a ton of experimentation while in school or early on in your career to understand what type of user research you enjoy and excel at most. It also means that it’s incredibly important to ask questions about the job description during an interview to make sure you’re not making faulty assumptions, based on a title, about the work you’d be doing.

Decisions influence data as much as data influences decisions.

I used to think the more data the better applied to most situations, something I’ve recently heard referred to as “metrics fetishism.” I’ve now observed many situations in which people use data as a crutch, end up making mistakes by interpreting “objective” data incorrectly, or become paralyzed by too much data.

The truth is that there are limitations to every type of data, qualitative and quantitative. Even data lauded by some as completely objective–for example, data from website logs or surveys–oftentimes includes a layer of subjectiveness.

At the beginning and end of any research project there are decisions to be made. What method should I use? What questions should I ask and how exactly should they be asked? Which metrics do we want to focus on? What data should we exclude? Is it OK to aggregate some data? What baselines should we compare to? These decisions should themselves be grounded in data and experience as much as possible, but they will almost always involve some subjectivity and intuition.

I’ll never forget one situation in which a team I worked with refused to address obvious issues and explore solutions without first surveying users for feedback (in large part because of politics). In this situation, the issues were so obvious that we should have felt comfortable using our expertise to address them. Because we didn’t trust making decisions without data in this case, we delayed fixing the issues, and our competitors gained a huge advantage. There’s obviously a lot more detail to this story, but you get the point: In this circumstance, I learned that relying on data as a crutch can be harmful.

What does this mean for your career?

Our job as user researchers is not only to deliver insights via data, but also to make sure people understand the limitations of data and when it should and shouldn’t be used. For this reason, a successful user researcher is one who’s comfortable saying “no” when research requests aren’t appropriate, in addition to explaining the limitations of research conducted. This is easier said than done, especially as a new user researcher, but I promise it becomes easier with practice.

You’re not a DVR.

Coming out of school, I thought my job as a user researcher was solely to report the facts: 5 out of 8 users failed this task, 50% gave the experience a score of satisfactory, and the like. I was to remain completely objective at all times and to deliver massive reports with as much supporting evidence as I could find.

I now think it’s old-school for user researchers to not have an opinion informed by research findings. Little is accomplished when a user researcher simply summarizes data; that’s what video recordings and log data are for. Instead, what’s impactful is when researchers help their teams prioritize findings and translate them into actionable terms. This process requires having an opinion, oftentimes filling in holes where data isn’t available or is ambiguous.

One project I supported early in my career involved a large ethnography. Six user researchers conducted over 60 hours of interviews with target users throughout the United States. Once all of the interviews were completed, we composed a report with over 100 PowerPoint slides and hours of video footage, summarizing all that was learned without making any concrete recommendations or prioritizing findings. Ultimately we received feedback that our report was mostly ignored because no one had time to read through it and it wasn’t clear how to respond to it. Not feedback you want to receive as a user researcher!

What does this mean for your career?

The most impactful user researchers I’ve encountered in my career take research insights one step further by connecting the dots between learnings and design and product requirements. You might never be at the same depth of product understanding as your fellow product managers and designers, but it’s important to know enough about their domains to translate your work into actionable terms.

Having an opinion is a scary thought for a lot of user researchers because it’s not always possible to remain 100% objective in bridging the gap between research insights and design and product decisions. But remember that there’s often always limitations and a subjective layer to data, so always remaining 100% objective just isn’t realistic to begin with.

Little is accomplished when data is simply regurgitated; our biggest impact is contributing to the conversation by providing actionable insights and recommendations that helps decision makers question their assumptions and biases.

Relationships aren’t optional, they’re essential.

As a student, my success was often measured by how hard I worked relative to others, resulting in a competitive environment. I continued the competitive behavior I learned in school when I first started working as a user researcher; I put my nose to the grindstone and gave little thought to relationships with my colleagues. What I quickly learned, however, is that taking time to establish coworker relationships is just as important as conducting sound research.

Work shouldn’t be a popularity contest, right? Right–but solid coworker relationships make it easier to include colleagues in the research process, transforming user research into the shared process it should be. And trust me, work is way more fun and meaningful if you enjoy your coworkers!

What does this mean for your career?

Take the time to get to know your coworkers on a personal level, offer unsolicited help, share a laugh, and take interest in the work that your colleagues do. I could share a personal example here, but instead let me refer you to Dale Carnegie’s book How to Win Friends and Influence People. Also check out Tomer Sharon’s book It’s Our Research.

Expect change–and make your own happiness within it.

Change is a constant for UX’ers. I’m on my eighth manager as a user researcher, and in my career I’ve been managed by user researchers, designers, product managers, and even someone with the title of VP of Strategic Planning. I’ve also been through four reorganizations and a layoff.

What does this mean for your career?

Change can be stressful, but when embraced and expected, you’ll find that there are benefits to change. For example, change can provide needed refreshment and new challenges after a period of stagnation. Change can also save you from a difficult project or a bad manager.

I remember a conversation with a UX leader in which he shared he once quit a job because he couldn’t get along with a peer who just didn’t get the user experience process. A few months after he quit, the peer was fired. If only he had stuck around for a while.

The U.S. Navy SEALs have a saying: “Get comfortable being uncomfortable,” which refers to the importance of remaining focused on the objective at hand in the middle of ongoing change. Our objective as user researchers is to conduct research for the purpose of improving products and experiences for people. Everything else is secondary–don’t get distracted.

For more detailed recommendations on how to deal with change as a user research, I highly recommend watching Andrea Lindman’s talk “Adapting to Change: UX Research in an Ever-Changing Business Environment.”

Concluding thoughts

I’ve been happy to see in the past two years that the user experience community has stepped up in making career advice more readily available (we could do even better, though). For user researchers wanting advice beyond what I’ve shared in this article, here are four of my favorite resources:

  • Judd Antin’s talk in which he covers many opportunities and challenges of doing user research: http://vimeo.com/77110204.
  • You in UX, an online career conference for user experience professionals.
  • Tomer Sharon’s book It’s Our Research.
  • A special issue of UXPA’s UX Magazine, with the theme of UX careers.

Creating Your Personal Mission Statement

Written by: Louis Rosenfeld

You’re weird. In a good way, but weird nonetheless.

Weird in the sense that people outside of work likely have absolutely no clue what it is you do. Maybe many at work as well.

For me, this weirdness manifests itself at parties. Inevitably, a new acquaintance asks me what I do. Beads of sweat form on my forehead. My eyes dart around, desperately seeking my far more articulate wife, Mary Jean. I find her, ask her to explain me, and flee.

If you’re in UX or a related field, congrats: You probably have more work than you can manage in a time when many people are underemployed. But that doesn’t diminish the discomfort those weird moments cause.

How might we explain ourselves better?

I created a simple exercise to help create personal mission statements—something short and meaningful to say about yourself—with some help and encouragement from Christina Wodtke and Anders Ramsay. It’s fun, simple, and quick; in fact, I recently tried it out with a group at the Re:Design conference and it seemed to work well. Here’s what to do.

Start with a context.

It could be public, like something to include on your business card, your Twitter bio, or blurt out at those nerve-wracking parties. Or something private, like a statement you write down and keep in your wallet for you and you only.

Tell your story.

Find a friend or colleague—someone you don’t mind being a bit vulnerable with—who will take notes while encouraging you to talk about yourself and what’s important to you. Ten minutes is plenty.

Basic questions like these can get you going:

  • What kind of change would you like to be part of?
  • What’s your superpower?
  • What’s the difference between what you’re expected to do and what you want to do with your life?
  • What has always pissed you off?

Craft a short statement.

Together, take those key terms and phrases from the notes and work them into something that fits the context you chose. Easier said than done, so plan to iterate.

At Re:Design, I was the guinea pig. My context was finding a new Twitter bio to replace this one:

Founder of Rosenfeld Media and veritable UX action hero.

“UX action hero” is an inside joke: pointless for 99.99% of the people who encounter my bio. Time to axe it.

I started with the “What has always pissed you off” question, and told my session’s attendees a story of 20+ years of frustration with the traditional business models (and their defenders) that I’ve encountered in higher ed, consulting, publishing, and professional associations. Telling one’s “true story” is never easy—especially in front of 70 people—but two things really helped:

  1. The floor is yours. Whether you’re telling your story to one person or 70, it’s your time. Take as much of the ten minutes as you wish, and make it clear that there will be opportunities to discuss your story and brainstorm after you’re done.
  2. Vulnerability is engaging. The goal isn’t to impress anyone with a slick presentation of your many fine attributes; rather, use this opportunity to begin figuring out what you’re about. Your stumbles and your quirky, imperfect, unfinished story will actually draw in your partner(s). If they have an ounce of empathy and interest in you, they’ll be able and eager to help brainstorm ideas about who you really are.

My group was anxious to brainstorm before I was even done telling my story. They came up with these options:

  • Happy but not satisfied
  • Re-architect/Assassin of business models since 1965
  • Shapeshifter
  • Internet sherpa
  • Learning by teaching
  • Step, pivot, repeat

My faves are the second and the last one especially, as verbs (like “step, pivot, repeat”) are fairly constant when it comes to describing how we live and what we do. And if I wasn’t happy with any of these, repeating the exercise with someone else would have made sense—after all, it takes less than a half hour. In fact, I’m considering repeating it as often as I get the urge—maybe once per year.

In any case, here’s my new Twitter bio:

Founder of Rosenfeld Media. Slayer of traditional business models. Step, pivot, repeat.

And here are shiny new Twitter bios from some of the session’s attendees:

helping people be less afraid of making things better

…and…

Persuade. Connect. Convince. Judging user experiences everywhere.

Though I’m not sure which questions got each of them started, I am sure they were excited. In fact, they were anxious to share their new personal mission statements with the group.

They found it fun, simple, and quick. I hope you will too.

Reorgs: Rocky or Righteous?

Written by: Rich Lee

As designers, we grapple every day with challenging projects. This of course is part of what keeps us coming back. Some challenges, although not directly related to project work, can still be looked at through a UX lens. In this case, I’m talking about a phenomenon you’re likely familiar with: company reorganization.

If you’ve been through a reorg (that’s ‘reorganization’ in water cooler parlance), you’ve probably experienced your share of the whispers, closed-door meetings, and mixed messages that seem to be par for the course when an organization goes through major changes in size, scope, staffing, or management.

I’ve been through a number of these shuffled decks myself, across several companies, and for a variety of reasons. It’s fair to claim that each one is different, but there’s enough overlap to identify patterns and form some baseline recommendations.

If you’re in a role with decision-making authority, then you’re ideally positioned to ensure that the reorg will be designed as an intentional experience with its actual user base in mind.

However, if you’re like the majority of us who aren’t in a position to make decisions about the reorg, you’re probably still reasonably close to the folks who are. Why not take the initiative and lay out some scenarios and recommendations for how the reorg can be designed for optimal reception and impact on your organization?

The users

Whether it’s planned or not, the scope of the reorg will have an audience far larger than the group of people seemingly affected on paper. The experience of these groups throughout the reorg should be purposefully designed by whomever is running the change management show.

Let’s take a look at who your users are.

  1. The folks who are officially part of the reorg. Their status is changing in some way, be it their actual role, reporting structure, or the like.
  2. Coworkers/teams who have direct or dotted-line dependencies with anyone or any team directly involved in the change.
  3. Coworkers/teams whose only connection is physical or cultural proximity or who ultimately report to the same upper management.
  4. Third party vendors who communicate with or provide services to reorg-affected parties.

Here’s what you need to realize: These groups will be getting bits and pieces of news about the reorg whether or not you craft that message explicitly.

With that in mind, you should ensure the messaging supports the business strategy, is accurate, and speaks to each party’s specific concerns.

This is the difference between an unplanned, unpredictable experience and an intentional, designed experience. It’s a golden opportunity to show your stakeholders they are a valued part of the organization, and you’ve got your arms firmly around managing the changes. If the right preparation goes into the reorg, you can nip in the bud any misinformation and unnecessary stress, building confidence in your team’s leadership and capability as a whole.

The alternative is to risk spending what trust currency you’ve accrued to date.

The message

Now that you know who you’re talking to, what do you say? It’s idealistic to think that you’ll know all the details when you begin planning the reorganization–but you do need to initiate your communications plan as close to the start of planning as you can.

Start by crafting general messaging that indicates the why–the logic being the necessity and desired benefits of the reorg. This should be high level until more details are known. If you know enough about the how to paint a low-res picture, do it.

A little bit of information that’s transparent and honest will go a long way–but take care not to make promises you can’t keep. Things can and will change, so own up to the reality that dates and other details are very much in flux to help you avoid having to take back your words when deadlines shift down the road.

As you approach major milestones in the reorg process and as the details solidify, provide appropriate communications to your audience groups–and do so again once the changes have been rolled out. This may seem like a lot of effort, but rest assured your people are asking questions. It’s up to you to address them proactively.

If a milestone date changes–and it will–the audience who’s been paying attention will still be looking to that date unless you update your wayfinding (in the form of project timeline communications). Without this careful attention to detail, you’re sharing bad information–perhaps more damaging than no information at all.

When the rubber meets the road

Inevitably, one question that will come up repeatedly throughout a reorg is “When does all this actually happen?” In other words, when do we start following the new processes, change how we route requests, start doing this and stop doing that?

For both logistical and psychological reasons, knowing how and when transitions will take place is vital. Often the difference between a stakeholder being stressed out (perhaps becoming a vocal opponent of the changes) versus being calm and confident is the company’s honest commitment to consciously bridging the transition with trained, capable support.

This could be as simple as a window of time during which existing persons or processes can continue to be called upon for support or as complex as an official schedule that shows specifically how and when both the responsibilities AND expectations of the audience segments will change.

Usability research

It’s not like you can do A:B testing with a reorg. You can, however, do some polling when the initial reorg information is shared, then midstream, and again after the reorg is complete.

Why do this research? As with any project, from your first person perspective, reorg elements might seem obvious–or you may have overlooked some pretty big pieces. Talking with your ‘users’ can be illuminating and also sends the message that their input is desired and valued.

While some reorgs are expressly designed to reduce overhead/staff, reorgs are not always about cutting heads. Often-times it’s a shuffle of resources (people), and if the right discussions happen you can guide that process to a win win.

Using a handy list written by a gentleman you may know of, here are some dimensions coopted for our use. Employ these as you see fit to generate interview material and discover how well your company reorg experience has been crafted.

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?

We can ask our participants what they took away from the reorg communications they were sent. This includes actual group or 1:1 meetings, formal documents, emails, etc.

Find out if the materials conveyed the message so the transition was easy to understand. Did they grasp both the high-level view and the granular details? (In other words, overall strategy and the specific impact to them.)

Efficiency: Once users have learned the design, how quickly can they perform tasks?

If the folks you’re polling have been assigned specific assignments in the reorg, ask early on if they fully understand their instructions and if they could have added any insight that might have decreased task costs or durations. Midstream or late in the game you can follow up to see if those instructions turned out to be clear and accurate enough for the tasks to have been carried out efficiently.

Did task instructions have the most time-saving sequence? Were there steps left out of the tasking communications that had to be discovered and completed?

Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?

Remember the telephone game? Someone makes up a story and then each player passes the story on to the next by whispering. When the story makes it back to the author, the details have changed–it’s a different story.

When those involved in a reorg talk with others, they’ll pass along what they know. The simpler the story and the more they’ve understood it, the less you’ll lose in translation.

Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?

A successful reorg requires a lot of work and collaboration between groups. Mistakes tend to be costly and have a ripple effect, becoming harder to correct as time goes on. The critical path of these big projects is placed at risk due to missteps due in large part to (wait for it) learnability and memorability, or due to errors introduced by people who have been put off by the lack of efficiency of the reorg process and attempt to forge their own path.

Another source of error is in failing to communicate enough timely information about role changes to employees and contractors. Major change breeds anxiety, and in a job market where workers have the power and employers are constantly on the prowl for good (and hard to find) talent, it’s a mistake to risk wholesale attrition.

Avoid this error by honestly and accurately communicating dates and the likelihood of roles continuing as is or with changes. If roles are going away, be transparent about that too. Better to maintain trust and respect with clear messaging about terminations than to leave folks in doubt and unable to plan for their future.

Satisfaction: How pleasant is it to use the design?

If the reorg does NOT leave a bad taste in everyone’s mouth, and if the stated project goals have been met, you’re doing it right. Reorgs happen for a reason, typically because something’s suboptimal or simply broken. Ultimately, everyone should pull together and work towards a positive outcome resulting in better workflow, lowered cost of doing business, increased job satisfaction, and, of course, $$$.

Moving on

Regardless of your role in the company and the reorg, consider whether or not you can use your UX superpowers to make the entire process less painful, easier to understand, and more likely to succeed.

Good luck!

Ending the UX Designer Drought

Written by: Fred Beecher

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

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

Mentorship

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.

Tracking

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!