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.
I went to art school. I studied painting until I fell out with the abstract expressionists and switched to photography. But I can draw.
What I cannot do is diagram. I always wanted to. I have models in my head all the time of how things work. But when it comes time to make a visual model of those ideas, I can’t figure out to to represent them. I find myself resorting to pre-existing models like four-squares or the Sierpinski triangle (I dig fractals.) For example:
Other than the oh-god-my-eyes color choices, my social architecture diagram has deeper problems. For example, the ideas in it are limited to threes within threes because that’s the form triangles take. The model served to communicate my ideas well enough for the sake of my workshop, but… shouldn’t form FOLLOW meaning? If I had more than four elements for any section, I’d have to either collapse two, or fudge it in some other way. I was sacrificing accuracy for consistency. But I didn’t know how to make to make it better.
A concept model is a visual representation of a set of ideas that clarifies the concept for both the thinker and the audience. It is a useful and powerful tool for user experience designers but also for business, engineering, and marketing… basically anyone who needs to communicate complexity. Which is most of us, these days.
The best known concept model in the user experience profession is probably Jesse James Garrett’s “Elements of User Experience.” The best known in start-up circles is the lean startup process. Both of these models encapsulate the ideas they hold in such a memorable way that they launched movements.
If you wish to clearly present a set of ideas to an audience and represent how they fit together, a diagram is much more powerful than words alone. Dan Roam points this out in his latest book, Blah Blah Blah:
“The more we draw, the more our ideas become visible, and as they become visible they become clear, and as they become clear they become easier to discuss—which in the virtuous cycle of visual thinking prompts us to discuss even more.”
Concept models can serve many purposes. You can use concept models to show your teammates how a complex website is organized before the site is built…
… or to help teammates understand how the site currently works…
… or to show end users how a service works, to help sell it.
I teach user experience design, and my syllabus always includes concept models. Students of mine who do a concept model before working on the interaction design and information architecture always make better and more coherent products. The act of ordering information forces them to think through how all the disparate elements of a product fit together.
The workshop was brain-candy and eye-opening: They covered how the brain processes information and how ways of interacting with information can promote understanding. BUT I still couldn’t make a model to save my life. I didn’t know where to begin!
At lunch, Stephen was manning the room while Karl grabbed food for them. I had been struggling with a model for negotiation I wanted for a talk I was presenting later in the program. Seeing Stephen idle, I pounced and begged for help.
Stephan P. Anderson is author of Seductive Interfaces and the upcoming Design for Understanding. He’s also a patient soul who will put up with ham-handed diagramming and ridiculous requests. He started to sketch my model and tell me what he was thinking as he drew. Then I had my bingo moment: Stephen had forgotten what it was like not to know how to begin! This happens to all experts. After a while some knowledge is so deeply embedded in their psyche they forgot what it was like not to know. They then teach the nuances rather than the fundamentals.
I suggested we do a think aloud protocol while he made a concept diagram; he would draw, and I’d prompt him to talk about what was going through his mind. He was excited to have me reflect his thinking back to him so he could become a better teacher as well. We arranged to have a sketching session after the workshop.
Later in the day, we met in the quiet hotel bar with wine and a sketchbook. I asked him what he wanted to draw. “Do you have something you are working on?” he asked. “That way I can focus on the model, rather than rethinking the ideas.”
Did I have a model I was struggling with? Always! I shared my new theory of the nature of digital products. I’ll be writing that up in another article when it’s done, but for now, the short version is that one must iterate through the elements of digital design, which include the framework, interactions, information structure, and aesthetics. But a product doesn’t become an experience until a person interacts with it; your design cannot be known until you see what happens when a human shows up.
Stephen’s first step was to ask me about my goal for the model. I said it was for students and young practitioners to understand the interdependencies of the elements, so they have a more iterative approach. And for critics to be able to understand why things are different, both good and bad.
Next, he did what I’d call a idea inventory. He brainstormed more elements that might play into the model. He made sure no ideas were left out. He made notes of those he suspected might be important in the margins. He sketched as he thought, sometimes just making meaningless marks, as if warming up his hands.
He then carefully asked about each element in my theory, making sure he understood each. What was an information structure and what was a framework and were they different? I ended up telling a little story about a product to make sure he got what I was explaining. I began to draw too, encouraged by his easy scribbles.
Finally, Stephen noted the relationships of the items to each other. Were some things subsets of others? Were some overlapping, or resulting?
Once he knew what each item was, and how they were related to each other, he began to sketch in earnest. He said, “I always start with circles because edges mean something. They mean you have four items, or five. Circles leave room for play.” His circles quickly became blobs and then shapes.
I don’t know if he’d normally talk to himself out loud when not encouraged to do so, but it was fascinating to to hear him free associate concepts, then draw them out. A string of concepts became a string of beads; moving through an experience became moving through a tunnel; intertwined ideas were a braid. Any important idea got a drawing.
Each time he completed a mini-model, he’d evaluate what was missing and what was working and take that insight to the next drawing. He made dozens of these little thumbnail drawings.
Stephen said, “one shape leads to another…a single word sparks a new representation—we’re always ‘pivoting’ from one thumbnail to the next…”
He pointed out what concepts were left out, or where they could be misinterpreted.
“You want to avoid 3-d, because it’s fraught with problems. You want to be able to sketch it on a napkin.” —Stephen Anderson, on keeping in mind the model’s goal
At one point, he became tapped out, and we spoke of other things. We stared out the window at the harbor, and I drank some of my wine, forgotten in the excitement of drawing and talking.
Then suddenly he started in again and produced a flurry of new drawings. I realized resting and mulling was important too. I was a bit annoyed with myself. An article doesn’t come out perfect in one writing session. Why should I expect a concept model to just materialize?
Finally he came to a stop, several pages filled with a jumble of images. We didn’t have a model, but we had many good directions. As we finished our drinks and headed toward the opening reception, Stephen told me, “You gotta get Dan Brown to do this, too.”
Dan M. Brown is best known in the user experience design community as author of Communicating Design and Designing Together. Both books benefit greatly by clear and succinct conceptual models, and the former even talks about how to use them in the design process:
Purpose—What are concept models for?
There really is only one reason to create a concept model: to understand the different kinds of information that the site needs to display. This structure can drive requirements for the page designs, helping you to determine how to link templates to each other. With the structure ironed out, you might also use the model to help scope your project—determining what parts of the site to build when.
Audience—Who uses them?
Use concept models for yourself. Ultimately, they are the most selfish, introspective, and self-indulgent artifact, a means for facilitating your own creative process.”
–Communicating Design: Developing Web Site Documentation for Design and Planning 2nd Edition, Dan Brown, 2010
Clearly, a guy I should be talking to!
The IA Summit was held in sunny San Diego in a hotel with not one but two swimming pools, so Dan had brought his family with him. When I asked him if I could watch him draw a concept model, he said, “I’m at the coffee shop with the boys around 6:30 every morning.”
You take what you can get.
The next morning Dan settled the boys in a corner with books, pastries, and an emergency iPad, and we got to work. We agreed he’d model the same concept, to control for variations. By now I had created a formula for the idea: (F+In+Is+Ae)+P=E. Framework, interactions, information structure, and aesthetics plus a person makes an experience. I was modeling in words as my friends were modeling in pictures.
I took Dan through the same story of an iterative product design process, since it had helped Stephen. I sketched it out. I felt like my hands were waking up from a long sleep, and they were eager to hold a pen now.
As I spoke, Dan wrote down key ideas and also began to scribble. He used the same process as Stephen: collecting the concepts then inspecting them for hidden complexity.
“A question I ask myself is ‘what needs unpacking?’ I can’t diagram an idea until it’s clear in my own brain.” —Dan Brown
He then took each concept and free associated all the sub-elements of the concept. He drew them out loosely, mind-map style.
Dan also started with the goal and wrote it out across the page.
He also asked explicitly who the model was for. To draw, he needed to visualize the audience. This reminded me of a recent presentation workshop at Duarte where we literally drew pictures of our audience. No work can be good unless you know who it’s for.
Dan made sure he didn’t carry anything in his head: All ideas were put on paper as a note or a sketch. When he had to turn a page, he ripped it out to lay it next to the other pages. I realized how critical it was to have plenty of room to see everything at once. I saw the same technique of storytelling and drawing of ideas.
Around now, Stephen joined us. He was excited to see what Dan came up with, enough to also climb out of bed at the crack of dawn. I listened as the two diagrammers discussed the poster session and the strengths and weaknesses of the ideas that had been presented.
Dan said, “You can look at people’s posters and see their process. They are so close to their own narrative…In one poster, the key framework was rendered in a very pale text. It was a good story, but there are things you want to jump off the page. For her, my guess is those steps were so self-evident she didn’t see need to highlight them.”
You have to have a beginner’s mind to explain to beginners.
“Speaking of beginner’s mind, so much of my design process is to throw it all out start all over again.” —Dan Brown
Now Dan began to model the concept. He emphasized the importance of sticking with very simple geometry–circles, squares, triangles, lines–not fussing with trying to find a perfect model at the beginning, just exploring the ideas and their relationships.
He also mentioned he begins with any concept in the model and doesn’t worry about representing order at first. He starts with what catches his interest to get familiar with the ideas.
Dan then deviated from Stephen by seeking the focal point. What concept held all the others together? What was the most important or key idea? He tried out placing one idea, then the other, in the center to see if felt right.
After scrapping one bowtie model, he paused. “I sometimes retreat into common structures and see how these common structures might speak to me. For example, time is one of those fundamental aspects, so I ask myself: How much do I need to show time here?”
He demonstrated by drawing swimlanes and sketched the ideas and their relationships in time.
“Are there other elements you often look for, like time?” I asked
“People,” he replied. “People and time are familiar concepts, easy for an audience to relate to. By using them as a foundation for a model, I’ve already made it easier for people to ‘get on board.'”
He stared at the paper, deep in thought.
Stephen then pointed at the page. “What Dan did here,” he said, poking at where Dan wrote out goal and audience, “I did also but didn’t externalize. I was holding it in my memory, but I like having it on the paper better.”
Eventually Dan, too, was tapped out, and his sons began to play Let It Go on the iPad at higher and higher volumes. He separated his sons from the electronics and left to prepare for the swimming pool.
After Dan, I knew I wanted to try to get one more person to model. Since I was lucky enough to be at a conference full of diagrammers, I chased Joe Elmendorf of The Understanding Group. He had just given a talk on Modeling for Clarity that my friends were raving about. And, with my luck still holding, I got to have breakfast with him. Happily, at 8 am this time.
Again, I saw what were becoming familiar concepts (inventory, inspection, relationships, then talk-draw.) I then focused on how he differed from Stephen and Dan. He choose to use the title of the diagram as an element. He did not iterate as widely as Stephen. He was the first person to argue with me about the validity of my theory, which was a great way to understand it (and benefited me by making it better!).
As well, he reinforced something Stephen had mentioned in his workshop and that Dan was obviously doing: Joe had a large mental library of typical models to draw upon, which got him started. Stephen keeps a Pinterest board full of inspiration, if you want to start your own “lego box” of models.
Overall, there were so many familiar patterns I saw in his approach, the differences were more interesting than important. I had my answer. I knew how they did it.
On the last day of the conference in the afternoon, Stephen and I were scribbling further on the model, playing with petals for the elements, when Dan Willis joined us. Dan is also a master of models as well as an inveterate sketcher.
Although Dan declined to diagram for me, claiming brain fatigue (a reasonable claim at this year’s Summit) he pulled up a chair and sat sketching next to us. It was companionable, to sit and talk and draw ideas. We moved back and forth from discussing life to discussing the ideas, teasing, joking, drawing. As we chatted, I realized this was a part of the secret. You need a thinking partner. Sometimes it’s paper, sometimes it’s friends; but it’s best when it’s both. It doesn’t always matter what you draw, just that you draw.
Dan Willis drawing nearby makes me happy.
Our brains work better when our hands are busy.
Later, sitting in the back of a session, I lobbed a model at Stephen, and he shot back with his own.
Then I saw another step, one which Dan had alluded to when he mentioned the poster with the key point too pale to read: You have to refine the model to communicate effectively. Type, color, and labels are all a key part of the communication process. While the model did stand alone without the color and type, adding those–and most especially getting labels right–made the model more effective.
After getting home, I started sketching how concept models were made. I drafted this article and then asked my friend Dave Gray if he’d do a quick edit. Dave was the founder of Xplane, a company that used diagrams–concept and other–to transform companies. Dave has been a proponent of visual thinking and clear modeling for years, and I consider him the master of making ideas visible.
Life then intervened and this article sat. I was busy with several things, including Lou Rosenfeld’s 32 Awesome Practical UX Tips. Dave presented right before me, and watching him sketch, I realized I just had to get one more diagramming session in. It was not enough to have him comment, I needed to see him draw. I was grateful I did; otherwise, I would have missed a crucial piece of the puzzle.
We hopped on a Google Hangout and he also drew out that same darn design model for me. I saw familiar patterns in his approach: inventory, unpack, relationship exploration. But he added a critical step I hadn’t thought of before: Test the model.
He’s currently writing a book on Agile, and it shows. He said, first design the test, then design the thing. For the model, he suggested using his WhoDo Gamestorming tool as a way to design a test of the effectiveness of the model. He lists who the model is for and what they will do if they understand the model.
Designing a test of the model’s success radically clarified the goals for the model. Testing it would make sure it did what you wanted it to do.
So then I sat down to make a model of how to make models. And it came easily.
Determine the goal: How will the model be used, by whom? What is the job of the model? To change minds, explain a concept, simplify complexity?
Inventory the concepts: Brainstorm many parts of your concept. Keep adding more in the margins as you go.
Inspect the concepts: Are there many concepts hiding in one? Do you really understand each idea?
Determine the relationships: How do the concepts interact?
Decision point: Do I understand the ideas and what I’m trying to communicate? Test: Ask yourself if the model “feels” right. If yes, then continue.
Iterate with words and pictures: Talk to yourself and draw it out!
Evaluate with yourself/the client: Keep making sure the drawings match the ideas you wish to communicate. Don’t punk out early! Rest if you need to!
Decision point: Does my audience understand the ideas and what I’m trying to communicate? Test: Can my audience answer key questions with the model? If yes, then continue.
Refine: Use color, type, line weight, and labels to make sure you are communicating clearly.
The concept model is invaluable. But like so many useful things, it takes time to make.
When my daughter first started drawing My Little Pony, she expected to start at the ears and draw it perfectly down to the hooves. She was angry when it didn’t work that way, and it took some convincing to get her to block out key shapes then refine the whole, and to use pencil before ink. When I sat down to make a concept model, I made the same mistake! I’d start in Powerpoint or Grafio, and expect perfection to flow from my mind.
No more! Stephen, Dan, Joe, and Dave taught me to play, explore, refine, test, and play some more until the result was right. Thank you all!
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?
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.
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.
Coworkers/teams who have direct or dotted-line dependencies with anyone or any team directly involved in the change.
Coworkers/teams whose only connection is physical or cultural proximity or who ultimately report to the same upper management.
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.
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.
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, $$$.
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.
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!
There was a time when the mere mention of artificial intelligence was wrapped in constant debate and triggered images of Hollywood-crafted products, like Hal 9000. The concept itself is quite controversial; it challenges human thought as Darwin once challenged human origins. But we moved on, and now we carry these intelligent machines in our pockets.
There’s a 38.9% chance you have one, too. Siri, the out-of-sight personal assistant from Apple, delivers an amazing experience. It listens to you, understands you, does what you say, and even talks back to you.
Sounds simple enough for us humans, but these are remarkable achievements for a machine. It has to process language, interpret context, understand intent, and orchestrate multiple services and information sources. And it brings together technologies that rely on dialog and natural language understandings, machine learning, evidential and probabilistic reasoning, ontology and knowledge representation, planning, and service delegation to do it.
Spin back the clock 50 years and all of this wasn’t even remotely possible. But just two years after Turing published the first documented idea of intelligent machines, three people were already working on the first system capable of speech recognition, named Audrey.
It could only process digits. Spoken by a single voice. With pauses in between. And it occupied a six-foot high relay rack.
Not exactly a marvel of technology, by today’ standards. But back then, when computers had only 1kb of RAM, it was an impressive achievement. More impressive still, when you think about how such a system came to be.
It all started with an illusion act
Many elements from very different spheres come together in the story of Siri, and it all starts with a man doing some magic.
Tracing Siri’s ancestry takes us back roughly 250 years, to Austria, when Vienna still had an empress. The story begins with a man known mostly for what was perhaps the most famous illusion in history: the Mechanical Turk, a machine that could play chess on its own and claimed to win over any opponent.
In reality, it was just a wooden cabinet with a life-size, mustache-wearing doll on top and a man inside, playing chess. It tricked people into thinking the machine was intelligent, but the idea itself was enough to intrigue the likes of Napoleon. (He played the Turk. He lost.)
And while the Turk made its creator—Wolfgang von Kempelen—popular, it is another of von Kempelen’s inventions that marks the beginning for Siri’s story.
The first speaking machine was a pretty straight-forward concept that tried to simulate the human vocal tracts—it had lungs and everything. Nevertheless, it was the first machine that could replicate whole words and sentences. It was this machine that would set the stage for Audrey.
Chess, the game that made it all possible
von Kempleton’s Turk was the first machine that could replicate human speech. Audrey was the first that could recognize human speech. But Siri is the first machine that can understand human speech.
Understanding is the unique ability that swings the story back to the Turk. The machine’s connection with chess isn’t random. Chess is more than a game; it’s an entirely mental activity. And it’s a perfect metaphor that would allow for the birth of a new scientific discipline, artificial intelligence.
A machine capable of defeating a human opponent at a mind game is an intelligent machine, by any logical standards—or, at least, that was the premise.
While the Turk was, for the first time in history, the first real image of a machine that could be better than us at anything, it was just an illusion with a man operating it. But ever since, the idea of an intelligent machine started slowly morphing into physical technologies.
The next obvious stage would certainly seem to be a machine that could play chess and be self-operated. In 1912, the real thing quickly followed. It was called Ajedrecista and it was the first computer game. Only, without an actual, you know, computer.
Making this happen required a deep understanding of how we think when we play chess.
Every move weaves together an amazing chain of mental processes: Perception transforms the pieces on the board into a series of symbols, and long-term memory overlaps perceptions with previous knowledge. Logical thought then searches for variations, and decision-making is needed for the actual move. (Intrigued like Napoleon? I found Chess Metaphors: Artificial Intelligence and the Human Mind quite useful.)
Move after move, the chess game becomes a sequence of decision-making events governed by strict logical rules. And it is this logic module in our brain that chess heavily stimulates, so much so that it can be simulated. It doesn’t take a big imaginary leap to imagine that thought can be simulated.
This realization gave way to wonderful theoretical breakthroughs. Concepts like an algorithms, recursiveness and programming were born. Having to analyze how we think about chess quickly lead to computer thinking.
AI: A new, old way of designing experiences
A special group of people made a great imaginative leap. They realized that a game holds the secret into human thought. For people like Edward Feigenbaum, Marvin Minsky, Allen Newell, Herbert Simon, Alan Turing, John von Neumann, and Norbert Wiener—the founders of AI as a scientific discipline—pinpointing all the mental processes that are necessary to generate high-level cognitive activities played a very important role in the development of simulated thought processes through computer programming.
Logic and process alone wasn’t enough though. We expanded our concepts to expert systems, knowledge engineering, neural networks, and so on. The subsequent knowledge-based models of thought are nothing short of amazing. But the real breakthrough came from an anti-type of approach: The father of expert systems, Edward Feigenbaum, called it representation. This approach supported the idea that knowledge-modeling the real world was much too difficult; instead, systems should adapt and respond effectively to real interactions with the world.
This is important because it has finally allowed for the development of a truly human-centered approach to designing systems, an approach initially articulated by Bill Moggridge and one which inspired a major shift in design thinking that we see maturing today.
AI and HCI have been described as having opposite views on how humans and computers should interact. Human-centered computing is somewhat bringing all that together by combining intelligent systems, human-computer interaction, and contextual design. Instead of trying to imitate (or substitute) the human, the goal is to amplify and extend his capabilities, much like a prostheses does, although not in the sense that they compensate for the specific disabilities of any given individual, but rather because they enable us to overcome the biological limitations shared by all of us.
Above all else, a prostheses needs to fit, otherwise it will be rejected. In the same manner, systems designed to assist, rather than replace, need to be personal and contextual. They need to be intelligent in order to fit.
In terms of actual capabilities, Siri wouldn’t pass a Turing Test. But it doesn’t set out to do so. It doesn’t try to augment our abilities, but rather extend them.
For example, say you want to go to the best restaurant around. You know you can do that. With the help of technology, you can combine information from different sources (local business directories, geospatial databases, restaurant guides, restaurant review sources, online reservation services, and your own favorites).
But why would you want to? You want to use technology as a tool, not get immersed in the experience of interacting with it.
Siri delegates everything you don’t want to do. It lets you use technology as it’s supposed to be used, as a tool. By doing so, it becomes a digital prostheses. As a result, the experience is truly human-centered, built for humans based on real human needs.
The story of Siri is full of great achievements of the human mind. It shows us how the power of thought can fuel great technological breakthroughs. It ends with the same man that started it all: von Kempelen, the man with the kind of thinking that gave birth to the first speaking machine, a truly amazing technological achievement. But more importantly, the kind of thinking that creates genuine human experiences.
The Turk’s biggest achievement was to challenge how we think about machines. This is the type of thinking that I like to call design thinking.
Yes, Siri still has its shortcomings, starting with the fact that it’s voice-controlled. But the mechanisms behind it are nothing short of amazing. Properly pairing machine intelligence with true contextual awareness is what created the first conversational interface that actually works.
And simply because it works, it marks an important milestone: It becomes a template for all future voice-controlled interactions. Even Google has updated its interfaces to include conversational and contextual interfaces. What Siri did was show the world a bright idea and made it stick.
More importantly, for professionals, the story behind Siri offers valuable lessons in true experience design, vital lessons in times clearly dominated by form instead of content, where an excessive preoccupation with formalism can impede further developments.
Experience design is more than numbers, boxes, and diagrams. It’s emotional, invisible at the time of inception, innovative, developed intelligently, and deeply contextual. A complex multiplex, feeding on a variety of different disciplines, such as neuroscience, psychology, linguistics, logic, biology, social sciences, computer science, software engineering, mathematics, and philosophy.
Much in the same way that Siri forges new tools from old technologies, good design feeds on AI for the raw materials to conquer human experience. To add function to experience. To add personality.
“Avoid fields. Jump fences.
Disciplinary boundaries and regulatory regimes are attempts to control the wilding of creative life. They are often understandable efforts to order what are manifold, complex, evolutionary processes. Our job is to jump the fences and cross the fields.”
The following is a composite of experiences I’ve had in the last year when talking with startups. Some dialog is paraphrased, some is verbatim, but I’ve tried to keep it as true as possible and not skew it towards anyone’s advantage or disadvantage.
As professionals in the user-centered design world, we are trained and inclined to think of product design as relying on a solid knowledge, frequently tested, of our potential users, their real-life needs and habits.
We’ve seen the return on investment in taking the time to observe users in their daily lives, in taking our ideas as hypotheses to be tested. But the founders and business people we often interview with have been trained in a different worldview, one in which their ideas are sprung fully formed like Athena from the brow of Zeus. This produces a tension when we come to demonstrate our value to their companies, their products, and their vision. We want to test; they want to build. Is there a way we can better talk and work together?
Most of my interactions with these startups were job interviews or consulting with an eye toward a more permanent position; the companies I spoke with ranged from “I’m a serial entrepreneur who wants to do something” to recent B-school grads in accelerator programs such as SkyDeck, to people I’ve met through networking events such as Hackers & Founders.
In these conversations, I tried to bring the good news of the value of user experience and user research but ran into a build-first mentality that not only depreciates the field but also sets the startup on a road to failure. Our questions of “What are the user needs?” are answered with “I know what I want.” We’re told to forget our processes and expertise and just build.
Can we? Should we? Or how can we make room for good UXD practices in this culture?
“I did the hard work of the idea; you just need to build it”
Over the past two years, I’ve been lucky to find enough academic research and contract work that I can afford to be picky about full-time employment (hinging on the mission and public-good component of potential employers). But self-education, the freelance “UX Team of One,” and Twitter conversations can’t really match the learning and practice potential of working with others, so I keep looking for full-time UX opportunities.
This has lately, by happenstance, meant startups in the San Francisco Bay area. So I’ve been talking to a lot of founders/want-to-be-founders/entrepreneurs (as they describe themselves).
But I keep running into the build-first mentality. And this is often a brick wall. I’m not saying I totally know best, but the disconnect in worldviews is a huge impediment to doing what I can, all of which I know can help a startup be better at its goals, so that it can have a fighting chance to be in that 10-20% that doesn’t end up on the dust heap of history.
“Build first” plays out with brutal regularity. The founders have an idea, which they see as the hard part; I’ve actually had people say, “You just need to implement my idea.” They have heard about something called “UX” but see user experience design as but a simple implementation of their idea.
As a result, the meaning of both the U and the X get glossed over.
The started-up startup
We’ll start with the amalgam of a startup that had already made it into an accelerator program. A round of funding, a web site, an iOS app, an origin story on (as you’d expect) TechCrunch.
It began with a proof of concept: A giant wall, Photoshopped onto a baseball stadium, of comments posted by the app’s users. The idea was basically to turn commercial spaces into the comments thread below any HuffPo story (granted, a way to place more advertising in front of people). The company was composed of the founder, fresh from B-school; a technical lead also just out of school; a few engineers; and sales/marketing, which was already pitching to companies.
The company was juggling both the mobile and web apps and shooting for feature-complete from the word Go. Though there were obvious issues, such as neither actually working and the lack of any existing comment walls or even any users; they were trying to build a house of cards with cards yet to be drawn.
In talking with the tech lead, I saw that they were aware of some issues (crashes, “it’s not elegant enough”) but didn’t see others (the web and mobile app having no consistent visual metaphors and interaction flows, typos, dead ends, and the like). To their credit, they wanted something better than what they had. Hence, hiring someone to do this “UX thing.” But what did they think UX was?
I had questions about the users. How did they differ from the customers–the locations that would host walls, which would generate revenue by serving ads to the users who posted comments?
I had questions about the company. What was their business process? What had they done so far?
This was, I thought, part of what being interviewed for a UX position would entail–showing how I’d go about thinking about the process.
I was more than ready to listen and learn; if I were to be a good fit, I’d be invested in making the product successful as well as developing a good experience for users. I was also prepared with some basic content strategy advice; suggestions about building a content strategy process seemed nicer than pointing out all the poor grammar and typos.
Soon, I was meeting with the founder. He talked about how a B-school professor had liked his idea and helped him get funding. I asked about the users. He responded by talking about selling to customers.
When he asked if I had questions, I asked, “What problem does this solve, for whom, and how do you know this?” It’s my standard question of any new project, and, I was learning, also a good gauge of where companies were in their process. He said he didn’t understand. He said that he had financial backing, so that was proof that there was a market for the app. What they wanted in a UX hire, he said, was someone to make what they had prettier, squash bugs, and help sell.
I got a bad feeling at that point; the founder dismissed the very idea of user research as distracting and taking time away from building his vision. Then I started talking about getting what they had in front of users, testing the hypotheses of the product, iterating the design based on this: all basic UX and Lean (and Lean UX!) to boot, at least to someone versed in the language and processes of both.
This, too, the founder saw as worse than worthless. He said it took resources away from selling and coding, and he thought that testing with users could leak the idea to competitors. So, no user research, no usability testing, no iteration of the design and product.
(Note on one of startups that’s part of this amalgam: As of this writing, there has been neither news nor updates to the company site since mid-2012, and though the app is still on the iTunes Store, it has too few reviews to have a public rating. This after receiving $1.2 million in seed funding in early 2012.)
The pre-start startup
I’ve also spoken with founders at earlier stages of starting up. One had been in marketing at large tech companies and wanted to combine publishing with social media. Another wrote me that they wanted to build an API for buying things online. I chatted with a B-school student who thought he’d invented the concept of jitneys (long story) and an economist who wanted to do something, though he wasn’t sure what, in the edu tech space. What they all had in common was a build-first mission. When I unpacked this, it became obvious that what they all meant was, “we don’t do research here.”
Like the company amalgam mentioned above, they all pushed back against suggestions to get out of the building (tm Steve Blank) to test their ideas against real users. Anything other than coding or even starting on the visual design of their products was seen as taking time away from delivering their ideas, which they were sure of (I heard a lot of “I took the class” and “we know the market” here).
And their ideas might end up being good ones–I can’t say. They seem largely well-intentioned, nice people. But when talking with them about how to make their product or service vital for users and therefore more likely to be a success, it soon becomes clear that what UX professionals see as vital tools and processes in helping create great experiences are seen quite differently by potential employers, to the point that even mentioning user research gets you shown the door. Politely, but still.
I’d like to bring up here the idea that perhaps we, as UX people, perhaps have contributed to the problem. The field is young and Protean, so the message of “what is UX?” can be garbled even if there were a good, concise answer. Also, in the past, user research has indeed been long and expensive and resulted in huge documents of requirements and so on, which the Lean UX movement is reacting to. So nobody’s totally innocent, to be sure. But that’s another article in the making (send positive votes to the editors).
One (anonymized) quote:
“Yep, blind building is a real disaster and time waste… I’ve seen huge brands go down that path… I have identified a great proof-of-concept market and have buy-in from some key players. My most immediate need, however, is a set of great product comps to help investors understand how the experience would work and what it might look like. I’ve actually done a really rough set of comps on my own, but while I’m a serious design snob, I am also terrible designer…”
So: Blind building is a real disaster, but she’s sketched out comps and just wants someone to make it look designed better. Perhaps she saw “buy in from some key players” as user research?
We had an extended exchange where I proposed lightweight, minimum-viable-product prototypes to test her hypotheses with potential users. She objected, afraid her idea would get out, that testing small parts of the idea was meaningless, that she didn’t have time, that it only mattered what the “players” thought, that she never saw this at the companies she worked at (in marketing).
Besides, her funding process was to show comps of how her idea would work to these key players, and testing would only appear to reduce confidence in her idea. (Later that week, I heard someone say how “demonstrating confidence” was the key ingredient in a successful Y Combinator application.)
“We’re looking for somebody who’s passionate about UI/UX to work with us on delivering this interface.
“Our industry specifics make us a game of throwing ideas around with stakeholders, seeing what sticks and building it as fast as possible. Speed unfortunately trumps excellence but all products consolidate while moving in the right direction.
“We certainly have the right direction business-wise and currently need to upgrade our interface. We require UX consulting on eliminating user difficulty in the process of buying, as well as an actual design for this.”
So: To him, it’s all about implementing an interface. Which, to him, is just smoothing user flows and, you know, coming up with a design. Frankly, I’m not sure how one could do this well, or with a user-centered ethic, without researching and interacting with potential users. I’m also not sure how to read his “upgrade our interface”; is that just picking better colors and shapes, in the absence of actual research and testing on whether it works well for users? That doesn’t strike me as useful, user-centric design. (During the interview process at Mozilla, I was asked the excellent question of how I’d distinguish art and design; I’m not sure I nailed the answer, but I suspect there’s more to design than picking colors and shapes.)
And I wasn’t sure even if he was receptive to the idea of users qua users in the first place. Before this exchange, when he described his business model, I pointed out that his users and his customers were two different sets of people and this can mean certain things from a design perspective. Given that his response was that they have been “throwing ideas around with stakeholders,” I gathered that his concept of testing with users was seeing what his funders liked. That did not bode well for actual user-centered design processes.
When I asked how they’d arrived at the current user flows and how they knew they were or weren’t good, he said that they internally step through them and show them to the investors (neither population is, again, the actual user). He was adamant both that talking to users would slow them down from building, and that because they were smart business people, they know they’re going in the right direction. It was at this point I thought that he and I were not speaking the same language.
I referred him to a visual designer I know who could do an excellent job.
I do not have the answers on how to bridge this fundamental gap between worldviews and processes. A good UX professional knows the value of user research and wants to bring that value to any company he or she joins. But though we can quote Blank, though we can show case studies, though we can show how a Gothelfian Lean UX process could be integrated into a hectic build schedule–when all this experience runs into a “build first” mentality, the experience and knowledge loses. At least in my experience. What is to be done?
It has been a very enjoyable experience working with everyone over the last couple of months and sharing our ideas on UX design. The various discussions about user interface, product usability, and user engagement have been an enlightening experience for me as well, and it is very positive to see that everyone involved in the product thinks so highly about improving the user experience.
In an ideal world with unlimited time and resources, I think the best way to address UX issues is to perform the same tasks as the user under the same environment/pressure–even if we’ve built something never done before–because then we would understand the exact problems that they have to solve and hopefully come up with the best solution.
User-centric design principles, however, do not replace the fact-finding mission we all need to take as UX designers; they merely serve as a starting point for making design decisions. We are not here to critique or provide expert opinions, but we are here to help ask the right questions and get the right answers from the users.
So, let’s talk for a minute about this thing we just launched.
What went wrong?
When you asked me what the users think without giving me time or money for research, you are in fact asking me what I think the users think.
When you asked me to apply standard guidelines and industry best practices, you are asking me to ignore what users have to say and to treat them like everyone else.
If our users are feeling a little bit neglected, it is because we’ve allowed ourselves to think we know better than they do.
Standards and guidelines abound, but not all of them apply. You have to know the rules first to know when to break them. These then need to be combined with as much knowledge or information as possible about our users so we can make some design decisions on the assumption that it is in their best interest.
Finally, we need to test and validate these assumptions so we can correct any misconceptions and continue to improve the product.
Somehow, SCRUM masters have convinced senior managers that standing in a circle in front of a board full of sticky notes constitutes a meeting and playing poker figures out the work schedule and priorities, but any suggestion of UX designers talking with end-users seems to be a waste of time and effort and not worth considering. If we aren’t given the right tools and resources to do our work, how can we be expected to deliver the best outcomes?
UX practitioners are not mind readers, and even if we do manage to guess right once, you can be assured that users won’t stay the same forever.
What could have gone right?
The more time you can spend thinking about UX and talking about it, the less time you will spend on fixing your products later.
If improving the user experience is something that the organization as a whole thinks is important, then everyone should be involved in UX design, just as the UX designer interacts with various people within the organization to come up with solutions.
Critical to improving an organization’s UX competency is removing the ‘black box’ view of UX design. There are definitely technical skills and knowledge involved, but I believe the most important skill for a UX practitioner is empathy, not Photoshop or CSS or how to read heatmap reports–as handy as those skills are to have and despite what many of the recruitment agencies would have you believe.
Certain aspects of UX design are familiar to all of us, in the visible and tangible part of the user experience. The user interface has a very visual and often subjective element to its design, but as a graphic designer can tell you, there are definite components (color, typography, layout, and the like) that are used in its creation. User interaction has a more technical and logical focus to its design because the nature of programming is modular and systematic.
Where I think people struggle to make a link with is the less accessible aspects of UX design, like dealing with user engagement of the product or the connection between the user experience of the product and the corporate brand/image. An organization may have many channels of communication with the end-users, but the messages spoken by the business unit can be very different than those of the product development team or customer support team.
Within the general scope of UX design there are different ways to involve the users: generating new ideas for product features, getting feedback on new releases/betas, running conferences or webinars, conducting research workshops, and so on, and it’s not as if organizations aren’t doing some of this already.
However worthwhile these activities are in themselves, if we make our decisions based on just one or two of them–or worse, carry any of them out but don’t act on the results–we’ve missed the opportunity to improve the user experience.
People who make complaints may just want attention–or perhaps they have been suffering for so long they can no longer deal with this unusable product. How do we know if all the complaints are filtering through customer support, and do fewer support tickets necessarily mean greater customer satisfaction?
Where to from here?
If we don’t like a particular color, we know how to change it. If a particular technology is incompatible, we can modify it or find an alternative.
But if we want to influence the behavior of our users, where do we start? Like any complex problem, the best way is to break the problem down into smaller and more manageable pieces.
If we want to make an impact on our product design, how do we go about it in the right manner? I think reversing some of the current attitudes toward UX design is a good starting point, because clearly the status quo is not creating the appropriate environment and culture for a UX-focused organization.
Don’t make the only UX designer in your company the UX team, don’t restrict the scope of UX design to the user interface alone, and don’t hide the users from the UX designers.
Do spend the time and resources to implement company-wide UX strategies, do try and understand UX design a little bit better, and do it as soon as possible.
But if we haven’t done anything yet, is it too late? Like everything else worth doing, it is never too late. However, not doing UX at all is probably not much worse than doing UX poorly. To act on good assumptions with caution beats acting on bad assumptions with confidence. A good UX designer knows that nothing about the user should be assumed or taken for granted, and we always need to be on our toes because just like the product, the user may see the need for change–even more readily than we do.
Having said that, if you don’t start taking small steps now, the challenge will become even greater. Make everything you do in UX design a learning experience that helps to reduce the problem.
If I haven’t lost you yet, then I think we are ready to talk some details.
Remember, there are a lot of standards and guidelines already, so we don’t need to reinvent the wheel–we just need to work out what works for us and what we can disregard.
As with any problem-solving process, we have to go through an iterative cycle of observing, hypothesizing, and testing until we derive at the optimal solution. I emphasize the word optimal, because there isn’t necessarily a right or wrong answer but there may be the most optimal solution given the circumstances (time, resources, assumptions…).
For those of you that have gone through the pain (and joy) of implementing Agile methodologies, I think you will agree that there is no out of the box solution that is guaranteed to work for any organization. You can certainly embrace the philosophy and principles, but how you adopt them to work for your team will be quite different depending on how you define the goals and objectives you want to achieve, not to mention the type of teams that you work with.
Remember, I am not here to critique or provide expert opinions, but to help you ask the right questions and get the right answers from the users. What UX means for the organization is up to you to decide, but if I have managed to spur you into some action, then I will have considered my job complete.
Through social psychology and cognitive science, we now know a great deal about our own frailties in the way that we seek, use, and understand information and data. On the web, user interface design may work to either exacerbate or counteract these biases. This article will give a brief overview of the science then look at possible ways that design and implementation can be employed to support better judgements. Continue reading Clicking Fast and Slow
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 werea 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!
A little background to start: I’ve had the honor of working as a designer-in-residence for General Assembly’s User Experience Design Immersive Pilot Program (UXDI) from June through July. Our team built, launched, and taught a UX course 5-days a week, 8-hours a day, for 8-weeks straight. It was quite the challenging, yet rewarding experience.
However, learning from our approach, I found something about the way we bring people into the fold that we can stand to improve.
We instructors spent much of our early days teaching techniques by going through truckloads of slides. We sent students home to read more chapters and articles loaded with paragraphs after paragraphs of definitions and use cases.
Yet, when students have trouble with a particular technique or concept during their free practice time, we’ve always had to re-explain to them the crux of these ideas with piercing simplicity.
Why don’t these simple core ideas exist in a simple, more easily referenceable form?
Looking up any UX terminology in Google results in many results: incomplete lists long abandoned, or gigantic lists of terms with accompanying paragraphs–and that’s only if you’re lucky enough to avoid the full blown articles. At a time when Dieter Rams’ As Little Design as Possible is common advocacy, we can present the fundamental impressions of UX’s core capabilities as something much more succinct than a wall of text. I’d argue that we would want the same considerations for our own products and content.
I have a modest proposal. Introduce the essence of your techniques and concepts in a single sentence. Do it in a one-liner. If it goes beyond one sentence, make it shorter.
Understand that these one-liners are NOT meant to explain UX techniques or concepts as well as articles or lengthy discussions can. Likewise, the real substance behind any of these techniques and ideas will expand and change over time, context, usage, and the like.
However, my contention is that there should be a much simpler and more concise way for people to see to the fundamental core of a technique or idea. For any confusion and disagreements that exists within the UX community, one of our common goals is to better communicate our ideas and intents to our teams and colleagues so that we can better create.
Why not then reconsider how we communicate the most basic fundamentals of what and how we work?
UX has always had a rich tradition steeped in academia, which is often somewhat verbose. It’s only relatively recently that its relevance to the consumer world has been realized on a massive scale. As UX adapts to a rapidly shortening cycles of technological–and by proxy, behavioral–change, we need to consider simplicity and conciseness in introducing the rest of our world to not only the products we design, but also the universe in which we create.
There will be another session of UXDI session beginning in September. I’ll be preparing a list for the students to use. Would you do it for a class you taught?
Here’s to an improved UX of UX.
Here are some one-liners I think adequately communicate the focus of their associated techniques and methodologies. This is a start. Add your own in the comments.
Activity in which users organize a set of data in ways that they think makes sense.
Ethnographic Interviewing technique where the user is observed using products in their natural usage setting.
Interviewing techniques combining one-on-one interviewing and extensive observation.
Preset categories used to filter information/content into more digestible chunks.
Quick rules of thumb used to streamline design decisions.
Data used to categorize other data.
Description of fictional yet realistic persons that represents a target user group/market.
A story describing a user’s problem situation and how she might use a product to achieve a solution.
Modular diagram conveying your site’s page inventory and, to a lesser extent, categories.
A test conducted with end users to see how usable they find a product.
A path map highlighting what a user has to do within your product to accomplish his goals.