I Am an Experience Designer and You Can, Too
I wrote this guide for a friend looking to transition to UX design. It made me happy to write, so I'll leave it here for those interested. I did not proofread it and I don't care.
User experience (UX) design, put simply, is the act of forming tangible experiences that cause or assist a user to complete a certain action or feel a certain way.
The keyword here is “tangible experiences”: others can design experiences as well, sure, but it is our sole ability and responsibility to translate them to something tangible; to materialize them in front of a player. We do this by holding the player at the center of our work's universe, considering them and their needs as we form systems and interfaces to guide them to their 'physical' – or emotional – destination.
To create a good user experience is a learned skill, inevitably brimming of trial and error. After all, the nature of this kind of work is to begin by making mistakes. These mistakes are tested, these tests produce results, and these results allow us to distill our creations to the point where they execute our intention as perfectly as possible (because in a space like this, perfection is never achievable).
How do you begin thinking like an experience designer? What is design thinking? Unfortunately, it might be impossible to simply transform you into a designer in the short span of a few paragraphs. Still, I can try to help you take the first step.
This Is Probably How You Will Need to Design
Design Thinking / The Experience Goal
Consider something near you. I will consider the eight ounces of to-go drip coffee next to me that I've half finished in the span of thirty minutes. This cup of coffee is not one, but two cups stacked on top of each other, with a plastic lid on top. The coffee is warm.
Why did the barista give me two cups? You might think the answers to be obvious: one cup would be too thin and could potentially burn me; two cups helps insulate the coffee so that it stays warm longer. And yes, these are the only answers; I have no reason to obscure any more from you. But to think of something and break down why it was made the way it is... that is the first step of design thinking. Then we simply reverse it.
In the design process, we start with an objective, an experience goal. We want a cafe patron to be able to comfortably consume their coffee. Simple enough. From there, we consider our user's demographic and their needs.
Consider the User
The average human is simple. They often fail to think before acting; thus, they have the potential to burn themselves on the coffee. But, they don't want to burn themselves!
The average human is also easily irritated. If something they paid for doesn't work out the way they want, there's a high chance they will get upset. Hot coffee cooling down quickly might make them punch a hole in our thin little plaster walls.
Okay, so we've thought about our customer and assumed some things about them. These are not the only traits of a coffee drinker, of course; we don't know everything! We never know everything. If we are unsure of what we might have missed, we can research to discover more factors in our decision-making. We can place a little survey next to the register of the shop, asking our customers how we can improve their experience. We can make user researchers analyze that data and provide us with design directions to follow, because data analysis is not the meat of our job, and we can then make more improvements that soothe those new qualms of our users.
Subsequently, after research, we make some informed design decisions. What if we lined our hot drinks with an additional cup at minimal cost, to ensure customers don't get hurt and sue the shit out of our dinky little third-wave coffee shop? And hey, that second cup would work well to keep our coffee warm for longer! And why not wrap the cups with a little cardboard sleeve, because Janine-53-years-old-who-buys-a-latte-every-two-days said that cup was too damn hot?
Everything I've said above is hopefully not groundbreaking to you at all. I've used all this dramatic and serious language, and you're probably sitting there thinking, “this girl is full of shit, because all the stuff she's pointing out is blatantly obvious”. And that's right! I'm full of shit. However, what might not be as obvious to you is that most people never consciously consider the reasons why something is the way it is, because good design is invisible design. Good design shouldn't make anyone stop and think (undesirable unless intended), because if so, we've slowed down the user or marred their experience (undesirable unless intended), and that makes both user and designer sad. So, if you're sitting there thinking “this is obvious and I already knew it all”, then that probably means we've achieved our purpose. Probably.
User Flow
So we've decided that two cups would help Janine out, and an additional cardboard sleeve would really help Janine out. How do we get these items into Janine's hands, so that she doesn't complain about the temperature of her coffee?
To begin, we try developing a user flow. This is where you, the designer, detail the chain of actions, choices, and expectations you envision the user to execute – via our design – in order to meet our desired experience goal. Creating a user flow takes time and detail-oriented thinking, because the designer must consider every possible state in the process. Where do we start? What can we assume? What are the causes and effects of decisions? What are our expected failure points and how do we resolve them back into our desired course of action?
An example flow for the solutions to our hot coffee dilemma would look something like this:
When a designer puts a user flow together, the chain of events should not be confusing to any random passerby viewing the flow. The final iteration of a user flow, after any review and feedback, should not generate new, relevant what-ifs, because we should be confident that we are accounting for, to the best of our abilities, every relevant possible state, cause, decision, action, and effect.
The Tangible Translation: Wireframes and Mockups
Time for the fun part: transforming plans into real existence! The coffee allegory becomes kinda irrelevant here: in that situation, the plan would simply be something along the lines of:
- increase the regular order of cups
- train baristas to follow expected user flow
- profit
But in the world of digital user experience, we mainly work with screen interfaces. To start, we look at our design decisions and user flow, and we identify:
- main screens
- subcomponents (widgets, panels, etc.)
- states of said screens and subcomponents.
Once these aspects are laid out (you can write a list of them if that helps!), we get to work, translating and aggregating them into wireframes. Wireframes are low-fidelity visual series of mockups of what users could expect to see and interact with in our games or software. They look something like this:
Panels. Buttons. Text. Tabs. But just that. Wireframes present no consideration of visual style. The size of things in a wireframe is not even final. It is tempting to add some kind of visual treatment, especially if you come from an artistic background, but doing so can impede upon the distinction between wireframe and visual mockup. The designer's sole focus here is to present all information to the viewer and user in a way that is simple and sensible. Make their experience of using the software easy.
Note that though there is no visual style applied, certain items have darker and lighter shades or outlines. It is important for our fellow developers to be able to at least slightly understand the difference between a button, a panel, something interactive, and something not. Of course, you can supplement this visual discernment with captions or notes for those who need to reference your work.
In the wireframing process, you should continue to consider end users, but do not forget another crucial set of users: your development compatriots. Who are you showing this to? An engineer who will implement your work? A designer who isn't familiar with how you might lay things out? Try to build your wireframes in ways that align with how they might use or interpret your work.
I've been mentioning
usersnonstop here. To put it harshly, we user experience designers are simply... vessels of design. While working, we exist and interact with the world solely for the sake of the user experience. Everyone else's thoughts are our priority – though that does not mean you should not consider your own instincts! You are usually also a demographic of the user base. Still, a good designer will be able to separate their biases from the real needs of their users.
Anyways. States. I have given you three frames here, which are all states of the same parent screen. The frames' relationship here is represented by consistent elements among all the frames and the changes in between them. This is important for understanding how the user flow applies between screens and components. For the viewer's convenience, I usually like to provide a key of those components that might change in between screens, and I tend to label major screen states in large text.
This is about as far as I can take you when it comes to wireframe construction guidelines. The intricacies of visual software are things best explained by the countless YouTube tutorials at your fingertips; I highly recommend turning to those for knowledge on auto-layout and prototyping. Good luck!
Presentation and Feedback
Your wireframes are done and ready to be presented? Time for the feedback gauntlet.
Presenting your work to designers and other stakeholders (be it producers, engineers, or anyone, really) is daunting. In a review meeting, the average designer will link their Figma file, screenshare, and walk through every screen/state/design functionality for the audience to comment on and tear apart. Knowledge of your work and the ability to concisely explain it becomes crucial. Some things to keep in mind:
Always understand the greater narrative of what you are trying to explain. You can easily and accidentally drift into granular detail, but your stakeholders are trying to understand how the feature works.
More than often, if not every time: your audience will pose questions or mention things that you didn't expect, or maybe forgot to cover in your designs. If that's the case, try not to view this as a failure on your part; instead, think of it more as a new thing to solve collectively.
- Remember, everything is WIP until it's approved. (Sometimes you can delegate questions to others based on the context! Sometimes you can also pose an idea on the spot and work it through, then mention you'll add that later.)
Engineers don't hate you. (this is hard to remember in the moment)
Butting heads with someone? Their feedback is valid, even if you don't think it is at first glance. As a UX designer, your duty is to listen and try to understand where they're coming from before making further statements. Ask them to explain themselves and focus on their reasoning in response to anything they say that seems outlandish. Maybe they actually see something you don't.
Leave every feedback meeting with an explicit understanding of what to do next. Make changes? Send links to people? Keep track of it all.
That Was Quick
I have only some confidence that I've covered even the majority of what you might need to know as a designer. I don't know if I can handle writing more. The truth is, you – the new designer – will learn a lot of this the hard way, through trial and error, and by getting burned by your mistakes. That's okay! Making mistakes is normal, as we know by now; it's how you respond to them and change your behavior going forward that counts.
Being a designer is wonderfully rewarding. The moment you see people using and enjoying the thing you made, you remember why you did it all; why you almost cried that one night at your computer, why you shook from sheer caffeine intake the other day as you hastily labeled your work for the review in one hour. This thing was once a scant few thoughts in your head, and now it is everyone else's to admire and hate and laugh at and break and use.
We designers are but simple creatures who only want to make useful, beautiful, delightful things for others to use. We dream to make people's lives easier, to help them have fun, to make them feel. It is easy to forget in the forest of everyday labor why we committed to creative work in the first place... but without this, what else do we have? What could be greater than the joy of creation? Are we anything without that which we love the most?
No. We are not. Now go forth and become a workaholic.