Horror Stories: The Importance of Defining the “Not-So-Happy” Path

Considering the messy extremes is critical to good user experience design. Whether it is planning for a million records instead of the five that fit neatly onto your screen, use of a 20 item navigation menu on a mobile phone, or how a dark backdrop with white text performs with glare during outside use, good design accounts for non-ideal situations, ensuring that the solution is scalable, extensible, and accessible under a variety of conditions.

Following is an excerpt from my upcoming book “The Storyteller: A Zombie Software Story”. Here, we see our team grappling with understanding how to think about designing for when things go wrong, starting with understanding the potential problems.

Max cleared his throat, trying to put his misgivings into words. “It’s a lot of moving parts with very little information.” He said finally. “I can see how we’ve got an ideal case, but there’s so much we don’t know…”

“Exactly!” Justin nearly shouted his interruption. “This is a total shot in the dark! How can you just make up a story like that and expect us to believe it will work? I mean, where’s the research? We should be planning this for months before we try to make a move! We don’t know if it will work at all.”

Manisha waited for Justin to wind down before she said “That’s an interesting perspective. Tell me, what information do you feel like is missing?”

Justin spluttered, gesticulating wildly in the air as he jerked back. “Market analysis! Problem verification! System compatibility!” he jumped up from his seat and started to pace. “I mean, sure, it’s an RFP so the market is pretty locked down, I guess. But problem verification is huge – you said yourself we need to keep it open-ended to make sure we’re solving the real problem, not what they imagine the problem is. And that takes time we just don’t have. I don’t see how we can get that to a high degree of confidence before we have to start coding the proof of concept. And then the system compatibility issues! What if we can’t make our software talk to each other? What if we can’t make it talk to the firmware the weapon has installed? What if…” he trailed off as he looked over at Angie. Max turned to see a slightly guilty smile on her face.

Justin stared “Angie….?”

She shrugged from where she sat, perched on the table “Hey, you guys didn’t think I made this decision in a vacuum did you? We did our due diligence prior to the acquisition. Have some faith in Owen and Ward – they’re smart guys. The firmware interface is another matter, but we’re doing investigations on that as we speak.” She turned to face them both. “Guys, this is an opportunity. A HUGE opportunity. And we are in a position to move quickly and take advantage of it. I know it seems fast, but we’ve all done things like this before. I’ll admit – there’s a risk. But it’s a calculated risk, not a foolhardy one. I need you both to get your running shoes on and stop belly aching about the fact that I moved your cheese.” She hopped down and started walking towards the door. “You know your stuff – you got this.” And then she was gone.

Max stared open mouthed at the empty doorway before shaking himself and turning back to Justin and Manisha.

“Well, that’s that, I guess.” He said with a shake of his head. “She’s right, of course. I’m more caught off guard than anything. “

Manisha smiled and nodded her understanding. “I’ve been involved since the beginning, so it’s a lot less of a surprise to me. I definitely understand how disconcerting all this can be.”

Justin crossed his arms with a frown. “Yeah, well, ‘disconcerting’ is sugar-coating it. I’d say fu…”

“Justin!” Max interrupted, cutting his eyes at Manisha.

“What? I can’t even express an opinon any more? Screw that! I’m out of here!” Justin stomped out of the room, muttering under his breath.

Max sighed. “He’ll cool down in an hour or two. This product is his baby and he just needs some time to get used to the idea.” He paused. “But he’s right that we’ve just got the happy path. How do we account for the not-so-happy paths?”

Manisha nodded “Horror stories. Right. We should be able to knock out a few of them now. We’ll be able to get more once the research team gets back with the contextual work so we have a better understanding of the current challenges.” She reached for the white board marker and started a new list titled ‘Trouble.’

“First, let’s list out potential failure points we’ll need to consider. Off the top of my head there’s visbility – the risk that they cannot see the targeting screen due to lighting conditions. Equipment failure – how do we handle an error within the hardware or software.”

Max chimed in. “Multiple targets, multiple users…oh, wait that’s not so much a failure point as a use case.”

Manisha started a second list title ‘Use Cases’. “Exactly. And we need to capture those too. Keep ‘em coming.”

After about 15 minutes they had added environmental factors (rain, cold, heat, etc.) and interference (enemy control of weapon) to their failure points. The use cases were proving harder.

“I just don’t have a good feel for the workflow on this.” Max grumbled. “And how are we going to turn this into …what did you call it?…’horror stories’?”

Manisha laughed. “Again, it’s not as hard as it seems. Let’s take visibility for example. We need to make stories that cover using the system when it is very bright, very dark, or the person using it is otherwise unable to see the interface.” She paused for a moment. “Take our original story, the dead squad in the high rise. You’ll remember the power is out and it’s poorly lit. Now, let’s add a line to the story about the gunner for this weapon. He wears prescription glasses and in the initial rush into the building they are knocked off his head and break.”

Max sighed. “Sounds a bit hokey, but ok, I’m game. So he can’t see well both due to lighting and losing his glasses.”

Manisha nodded “Once we get everyone back together, we can test that scenario out and see if it holds. If it does, we write requirements for eyes-free operation.”

Max was unconvinced. “Look, I don’t want to be disrespectful, but it seems to me that this is a lot of extra window dressing without a good return. I mean, I like a good story as much as anyone! I’m just not getting it.”

Manisha again, just nodded. “I know, it’s hard to see the value at first. It seems silly and like extra work for no reason. The return comes when you get multiple people involved. That’s the point when you need stories the most. It keeps everyone on the same page and ensures you’re seeing things the same way – or at least know that you are not seeing things the same way.” She paused, thinking. “Have you ever designed something perfectly to Justin’s specifications but had him come back and tell you that wasn’t what he asked for?”

Max looked down, a bit uncomfortable. “Well, sure. All the designers I know have that problem. Product managers are just…well, they aren’t always that good at writing requirements, you know? Plus they’re always coming up with new stuff to push into it and…” he trailed off, starting to understand.

Manisha prompted “And it’s like they aren’t on the same page as you? Like they have a different idea in their head?”

Nodding slowly, Max conceded, “Just like that. I’m not totally convinced stories will help that, but I guess I’m willing to try.”

Look for monthly excerpts – the book is coming out in 2017!

Defining Problems

Defining problems is a key and often overlooked step in software development.  Everyone like to solve problems – but determining what the problem is first can save time and ensure the solution is something extraordinary.

Excerpt from Chapter 2 of The Storyteller: A Zombie Software Story:

Max nearly choked on his bagel. After scalding his mouth on the coffee in an attempt to get the rest of the bagel down, he sputtered “One MONTH? To integrate two completely different code bases with a hardware interface? And that doesn’t even begin to touch on the workflow integration for a system that has to be field ready for God-only-knows what user base?  Are you INSANE?”

The lead developer barked a laugh which turned into a cough as Ben elbowed his ribs. Manisha nodded her head sympathetically. “I know it’s a lot to take in, but I’m confident that if we follow our story process, we’ll be able to come up with POC that will not only satisfy the government requirements, but that will give us the blue print we  need to make a really great product.”

Max just stared at her open-mouthed.  She didn’t seem like a crazy person, but what she just said was, without a doubt, crazy.

Angie snickered “Close your mouth, Max, before you start catching flies!”

Manisha smiled, nodding to the white board wall behind him. “Let me explain.”

She walked up to the wall, snagging a marker on her way past the table. She started to draw as she talked.

“Since humans first started to communicate, they have done so in stories. “

She drew two stick figures facing each other.

“Stories give us, not just the facts, but how the person telling the story sees those facts.  They give us context” She drew a blob between the people and gave each person  a thought bubble – one had a circle in it, the other a square. Then the person with the circle started talking and had a speech bubble with the blob = circle.

“By telling each other stories, we are able to see things from other people’s perspectives and help other people see our perspective.”

She added a circle to the thought bubble with a square and put an equals with a question mark over it.

“This lets us come to a common understanding a move forward”

She erased the blob and made a square with rounded corners, replacing the contents of the thought bubbles with the same shape.

“Stories also help us understand patterns”

Now she drew two new stick figures. One had a speech bubble with three stars, one circle and three more stars.  The other had a thought bubble with three stars, one circle, three stars, one circle and then three dots.

“…even if we can’t see the patterns ourselves.”

Max nodded his head reluctantly. “OK, that’s all nice but how is that going to make this insanity you guys have cooked up doable?”

Manisha erased her drawings and wrote ‘Problem’ as high as she could reach. It was not very high. Then she turned to Max “To tell a story, first you need to know the problem that the characters are trying to solve.  So, let’s talk about what our problem is.”

Max leaned back, thinking. This was a lot like some of the design sprints they had run at the game studio he’d worked at prior to Where’s The Zombie.  You had to define the problem before you could get on with the solution.

“OK – talk me through the problem.”

Manisha took a moment to take a drink from her thermos before continuing. The elaborate scrollwork on the metal seemed a stark and artful contrast to the somewhat sterile conference table, and Max wondered what she was drinking. Tea? If he had to bet, he would bet it was tea.

“We have several problems, “ Manisha said, returning to the white board. “Let’s start with how we’re defining problems.

For our purpose, a problem is a situation or event that we want to change to achieve a different result.  The problem definition should include both the problem statement – that is what the situation or event is – as well as the desired result. The important thing is to avoid trying to solve the problem in the problem definition.”

Max nodded vigorously, glancing sidelong at Angie.  She was studying her shoes, deliberately not looking up. This was an old argument they’d had many times – she had a tendency to want to jump straight into problem solving mode and had a hard time understanding why that was an issue.

“Exactly” Max said, “It’s like asking someone to build you a car instead of asking them to build you a way to transport individuals and their belongings from one point to another.”

Manisha smiled again “Precisely. By defining the problem, you determine all of the requirements. In your example, you would need to define how many individuals would need to be transported at one time, under what circumstances, how frequently, and so on.”

“But,” Angie interjected looking a bit miffed “Then you might design a bicycle or a scooter or something!  And I wanted a car!”

“Do you?” Manisha asked, unperturbed by the interruption.”By defining your requirements well without suggesting a solution, you might end up getting a teleportation device or something equally amazing. There are a number of excellent examples of how well-defined problems lead to superior solutions from the oil industry to medical research[1]. Defining a problem well is both difficult and rewarding.  It can lead to true innovation or could identify new directions. It ensures that you are creating a solution that has no problem.

At Virtual Zombie, we’ve discovered that creating stories helps us better define problems.  Let me show you what I mean.”

On the board, she drew three large squares, like a cartoon series. In the first, she drew a stick figure with it’s hands in the air and a thought bubble that said “oh no! Zombies” with another angry looking stick figure reaching for it.  In the second square, she drew the same two figures, with a third pointing a gun with the label “new” at the zombie saying “I’ll save you”. The third box had the zombie sticking it’s tongue out at the figure with the gun saying “Missed me sucker!”

Max snorted. “So our problem is that zombies are sassy?”

Manisha laughed “If only!  Our problem is that we need to protect people from zombies. We want to use the governments invention, but the new weapon does not do a good job of targeting. It’s not very mobile or easy to use, like a rifle or a handgun.”

Intrigued, Max asked “What are the specifications?”

“Good question!” Jolene slid a stack of papers over to him.  Justin scooted a chair over to take a look. Max started reading through the papers. The weapon was unwieldy and heavy – it had to be mounted on something that could move it around.  Accuracy was important for disruption of the zombie but shooting innocent civilians wouldn’t be an issue as the pulse was not harmful to regular humans.

Justin looked up “So, why don’t they just widen the beam? It says here that tests on humans showed no reaction – why not just make it like a big area effect?”

Jolene nodded at the papers “Keep reading.”

Max had already reached the answer “Look here “he pointed to a diagram” It’s effectiveness becomes diluted as the beam becomes larger. Larger than a basketball and it becomes useless. It’s got to be…let’s see… 2 inches in diameter for optimal effect.” He looked up at Manisha and Jolene in surprise. “That’s tight! How accurate can you be with the VZ software?”

The lead developer, a young man with long dark hair spoke up – Max tried to remember his name…Winston? Wesley? William? Definition a W-something…

“Accuracy won’t be the issue in a single case – it’s scaling it to large groups that require retargeting that hits our limit. We can model singular zombie movements to within tolerance.”

Manisha moved back to the board and under Problem she wrote ‘protect humans from zombies’. Under that she started a bulleted list titled Requirements ‘use government weapon’ ‘retargeting’ ‘accuracy to 2 inches’.

[1] https://hbr.org/2012/09/the-power-of-defining-the-prob

Not Just Once Upon A Time: Understanding the Relevance of Stories

The following is an excerpt from my upcoming book “The Storyteller: A Zombie Software Story”

When I was a child, I loved stories.  I loved to hear them, I loved to tell them, I loved to write them.  It seemed to me that the whole world was filled with stories, if you were only willing to listen. Whether it is to the charming elderly man on the train telling me how he used to dance in thunderstorms without fear because lightening is nothing but the shoes of the angels striking the clouds as they dance, or the proud crowing of a parent in the grocery store whose child just took first place in her chess tournament, or the product manager relaying how he sees a certain friend once a year to watch him run a marathon and how that experience inspired him to create an app for spectators – I love stories because they give you the version of the world as seen through someone else’s eyes.  And in that vision lives perspective, context, and understanding.

What Is A Story

On its surface, a story is a narrative that describes a series of events – an accounting of something either fictional or non-fictional.  However, ask any child and they will be quick to tell you that a list of what happened – whether real or imagined – is NOT a story. So what then differentiates the simple recounting of events from a tale worth telling?  The secret to stories is meaning.[1] When we tell a story, we give the events we are recounting meaning through the details we provide, the details we leave out, the tone, the context, the characters, and the conclusion. We provide our listener or reader, not just a series of facts, but our interpretation of those facts.

Stories can be made of words, images, or sounds – a short film clip showing current conditions in a war-torn country, a well-drawn political cartoon, the recounting of a site visit by a product manager, the headliner in a newspaper – all of these are stories. Regardless of the format used, they convey the storytellers perspective of an event or situation, their reaction to it, the filter they use to understand it.

The Power of Stories

The power of stories lies, not in the entertainment they may provide, but in the glimpse into another person’s mind and vision, as a participant rather than an observer. Stories show you how other people see the world and those things that happen within that world. They let us see how another person’s interpretation of events is different from our own and how it is the same. They let us cheat Schrodinger’s cat and observe it simultaneously alive and dead. And once we have that perspective, they give us the power to show others how we see the world.

Persuade

One of the most common uses for stories is to persuade. Think about the commercials you see every day, whether on the television, the radio, in magazines, or on the internet. A good commercial tells a story to persuade you to see things from the advertiser’s point of view. One story might show a young woman out on a date with a young man in a fancy sports car. What story does this scene imply about the role of the car for this young man? Another shows a happy family seated around a table, laughing and conversing, about to eat a prepackaged convenience food that looks tantalizingly delicious.  By showing us a story of a happy family who eats together, what is the advertiser persuading us to believe? Stories have the power to associate powerful imagery with strong emotions, leading the audience to conclusions they might not have drawn otherwise. [2]

Our team was having a challenging time explaining the reason we were making some improvements to some planning software to a client. The team was getting frustrated – they had shown the numbers, time on task, and so on, but the client just wasn’t getting it. Taking a step back,we created a story about a young woman who wanted to take a trip to walk them through the full set of changes. We explained how excited the young woman was to go on the trip, but that she was anxious too because she’d never done anything like this before. At each step of her journey, we told her story and how our designs had helped her, keeping her feeling connected and calm. After the presentation, the client came to me to say “You guys really get it – this is how our customers live!” They approved the changes the same day and we were able to move forward.  The challenge had been that they couldn’t “see” the numbers.  They weren’t real, weren’t the people they dealt with on a daily basis. It took creating story to explain a vision that we could share with them to help persuade them to see our perspective.

Educate

Stories make things more memorable. Whether used as a coaching tool or a way to help people understand a new concept or process, stories make things relatable. As pattern-seeking creatures, our brains are wired to look for stories and patterns[3]. By providing the story for our audience, we give them context to make sense of what we are trying to communicate.

While teaching some designers about understanding context of use, I used this story to illustrate a situation the check in software they were designing needed to address:

The day started like any other, with Miss Mary Martinez checking in the children into the YMCAKidzone. There were so many things planned for the day – making paper flowers, feeding the goldfish, learning how to count to five, and let’s not forget JillianGorfman’s birthday cupcakes that afternoon – that Miss Mary was not quite paying attention to all the little heads coming through her door. At the end of the day, she prepared for the parents to come pick up their sticky little darlings, wiping cupcake icing from their ears and reassuring them that it would be their turn any moment. But wait!  She counted the ears she had wiped and came up with 2 too few!  Quickly checking her roster, she noticed that in her hurry this morning she had failed to check every child in. She quickly checks in the ones she can see but Sue EllenDempsieis no where to be found. Did she make it in this morning? Miss Mary can’t remember and unfortunately Sue Ellen is a “hider.” She starts to sweat, checking every possible hiding place Sue Ellen might be.

Once they had internalized the story, I started asking questions.  What do we know about the environment that check in software is used in? What level of care and attention is the teacher able to give the software? What does this tell you about the design?  The students were able to quickly hone in on the need for a simple interface with potentially a fail-safe check feature,  through a physical interaction with the child (swipe a badge, quick photo of the child) or perhaps a dual check in (once at the facility level and once at the class level) or potentially an alert that let the teacher know if all expected children had not checked in. The original design proposals that had reporting features, options for assigning nicknames and so on, were adjusted based on a more visceral understanding of the situation.

Communicate

Every person has their own set of stories.  They collect them from the time they are born, adding their own narratives about their personal experiences as well as the narratives of their peers, their mentors, and their society. Those stories inform how they understand the world, the filter through which they see things. Understanding those stories on each level can make or break the communication between two people. On a cultural-level[4], stories can inform an entire society’s attitude toward impactful things such as expected behaviors and outcomes, organizational responsibilities and authority, and acceptable uncertainties.

When working with my team in China, I have been asked “how can I better understand the end users when they are Americans.” YouTube is a great resource for this, as you can find endless videos people have made of themselves enjoying the very activities our software supports – telling their stories. However, for a deeper understanding of cultural differences, I frequently point to children’s stories. Children’s stories represent the moral lessons we want our children to learn.  Take the classic tale of Cinderella – hard work and tolerance in the face of abuse will eventually pay off royally! Good triumphs over evil.  Contrast this with classic Chinese folk tales and you will see a very different message – one of balance, of the need for both good and evil, and the turning of the wheel. As I pointed this out to my team, one of the designers suddenly had an “ah ha!” look on her face.  When I asked her about it, she said she realized now why her North American colleagues always celebrated when they hit a milestone.  She said “It’s like they didn’t even know that this was just temporary and that something else would come up to push us down again in the cycle.” The difference in approach is part of our cultural story.

[1] Martin, P. (2012) How to Write Your Best Story: Advice for Writers On Spinning an Enchanting Tale, Crickhollow Books.

[2] Baldoni, J (March 24, 2011) Using Stories to Persuade https://hbr.org/2011/03/using-stories-as-a-tool-of-per

[3] Melanie C. Green. Storytelling in teaching. Association for Psychological Science. April 2004.

[4] Hofstede, G., Hofstede, G.J., and Minkov, M. (2010) Cultures and Organizations: Software of the Mind. Revised and Expanded 3rd Edition. New York: McGraw-Hill

 

 

UX Jedi Mind Tricks Lesson Two: Your eyes can deceive you; don’t trust them

POV

The next step on our road to becoming a UX Jedi Master, is listening. Not hearing, being engaged, paying attention, or concentrating. None of these things is listening.

So what is listening?

Listening is the process of hearing what someone else is saying without thinking about what you are going to say next. (Because, it’s all about you, right? ) When you listen, you no longer are crafting the perfect counter argument, witty rejoinder, internet factoid, or dredged up memory from your 6th grade math class. You are (wait for it…) listening. You are accepting the information that the other person gives you. That’s it.After they have completed talking, then, and only then, you can start thinking about what they meant, how to respond, whether or not you agree, and so on.

Sounds simple, right? WRONG! Real listening (sometimes called active listening) is one of the most difficult, trying, strenuous, and nerve racking things you can attempt. It is not easy or fun! BUT, it is bloody effective.

Why is listening important for a UX Jedi Master?

  • Gathering an accurate view of information. Listening prevents you from applying filters prematurely to the information you are gathering. When you start to form an opinion or action list about information while it is still being conveyed, your brain starts to eliminate or filter out anything that doesn’t fit. As a result, you get an incomplete picture and end up missing things. When you do not listen, you are unable to see other people’s point of view accurately. And without an accurate view, you are unable to persuade or argue effectively.
  • Making other people feel valued. Imagine, if you will, that you are telling someone a less-than-compelling story about the first time you got called on in class. The first person you tell the story to is smiling and looking at you, and nodding their head vigorously. As soon as you take a breath, they immediately start telling you an amusing anecdote about their own first pressure situation. You feel a bit put-off, but they weren’t being rude and they were paying attention, so you can’t really get upset. But you’re happy when the story is over and you can move on. A little while later, you tell your story to a second person. They put down their drink, look at you directly and nod slightly throughout your story at key points, never saying a word. When you are clearly finished, they do something odd – they pause as if they are thinking about everything you said. Then they tell you almost the exact same anecdote that the first person told. You find it much more interesting this time – somehow it seems more relevant and funnier. You feel like they are really interested in you. When people feel valued, they are more inclined to value you and your opinions or positions.

So how do you learn to listen?

  • Feign ignorance. Or, more precisely, assume (inside your own head) you know nothing at all about what the person is telling you or about the person themselves.
    Wipe the slate clean and pretend that this is the first time you have heard about whatever they are discussing. Forget about that incident at the company Christmas part with the Groucho Marx glasses and the beer bottle. If you can approach them with fresh eyes and ears, you will be able to listen. CAVEAT: Do not actually pretend you don’t know them. That will not only not help, but also be really really confusing for everyone.
  • Pretend there will be a quiz at the end.
    To keep yourself engaged and present, pretend there will be a quiz at the end during which you’ll need to sum up all the key points the person just gave you. Ask questions if something confuses you (you’d ask a teacher who was going to give you a quiz – feel free to ask your speaker too) and summarize their responses to make sure you go it right
  • Practice, practice, practice!

While difficult, listening is a keystone in the UX Jedi’s arsenal, upon which many other more subtle techniques depend.

Your eyes can deceive you; don’t trust them” Obi Wan Kenobi

 

A Short Word on ALL CAPS

The use of ALL CAPS in electronic documents and missives is generally considered to slow reading speed[1][2] [3](impacting the usability and readability of text) and to be interpreted as “shouting” at the reader[4]. However, ALL CAPS seems to continue to be in common usage in legal documents throughout the internet. It is worth taking a brief look at the history of this practice to understand it better.

The use of ALL CAPS in legal documents stems from the requirement that lawyers make particular passages “conspicuous” to ensure that a reasonable person would notice them[5].  Historically, the only way to make text conspicuous on a typewriter was the use of ALL CAPS. However, this approach is not actually required.  Conspicuous, as defined in the Uniform Commercial Code (UCC 1-201b) (https://www.law.cornell.edu/ucc/1/1-201)is:

(A) a heading in capitals equal to or greater in size than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same or lesser size; and

(B) language in the body of a record or display in larger type than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same size, or set off from surrounding text of the same size by symbols or other marks that call attention to the language.”

Clearly there are other options that are less “offensive” and will support the user in reading and comprehending legal materials more quickly. And it’s never too late to change. The US Navy switched from ALL CAPS to mixed case in their messaging system in 2013 after using ALL CAPS since the 1850’s.[6]

[1] How We Read (August 2014) Jason Santa Maria http://alistapart.com/article/how-we-read

[2] Writing Readable Content (And Why ALL CAPS Is So Hard To Read) (November 2011) Marty Friedel https://www.digitalcookie.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read.html

[3] The Science of Word Recognition Kevin Larson (July 2004) http://www.microsoft.com/typography/ctfonts/wordrecognition.aspx

[4] How capital letters became internet code for shouting (April 2014) Alice Robb, NewStatesman http://www.newstatesman.com/sci-tech/2014/04/how-capital-letters-became-internet-code-shouting

[5] A Quick Note on Conspicuous Text, also known as ALL CAPS (August 2012)Luis Villa http://lu.is/blog/2012/08/19/a-quick-note-on-conspicuous-text-also-known-as-all-caps/

[6] US Navy Adjusts to the times;ditches its ALL CAPS message format (June 2013) Ed Payne http://www.cnn.com/2013/06/13/us/navy-all-caps/index.html

Roles in UX

UX Roles
How UX Roles: Information Architect, Interaction Design, Visual Design, User Research, and Front End Engineering

I’m not a fan a labels on people.  On food, form fields, and bathrooms, sure – but not people.  People are mutable, rarely fitting into one nicely defined category.  And in UX, this is definitely the case. However, since UX spans such a wide-range of skills, it’s occasionally helpful to provide role definitely so that people know that there’s a lot more out there than just wireframes and visual comps. So here’s a very crude way of understanding the different roles (often held by the same person!) in UX.

Imagine you need to build a road.  You go to your UX team:

Information Architect: “We must make signs so people know where to go. And those signs should be in a consistent order so they can navigate to where they need to be.”

Interaction Designer: “We must build on and off ramps and a divider to make traffic flow intuitive. They should be able to mark their favorite places in their GPS to make sure they can get back to them over and over.”

Visual Designer: “We must ensure the center line, signs, and ramps are easy to see and call attention to themselves. It should be fresh and modern and appealing.”

User Researcher: ” We must understand how many people will drive on this road and when. That will tell us how many on and off ramps to create, where to create them, which signs are needed and in what language, and what our tolerances are.”

Front End Engineer: “Guys…there’s a big mountain in the way…”

(Need I say it? Always involve development…)