Foreword
It is worth noting that not every project follows the same path, due to time-, money-, and people constraints, and in many cases (unfortunately) only some of the steps are included in day-to-day product development scenarios. The framework I’m loosely using as a guideline for my work is Design Thinking. Since I cannot use whatever material I got from the field to illustrate this post, I use snippets from a "Pizza Time" practice project I did for the "Google UX Design Certificate" program. The purpose of this post is to explain how I work as a (generalist) UX Designer, with the goal to design good products.
1.) Empathize
I am trying to solve the problems of the users, either from the get-go when our team is building a new application or afterward when I need to fix the mistakes that already exist in production. I need to understand the users for whom I'm designing the product. Ideally, this should happen before a single line of code is written, a good user experience very rarely can be baked in, as an afterthought.
So, after the new project has been outlined into tickets, the work typically begins with having discussions with the user(s) and/or stakeholders, either virtually or face-to-face. In these discussions, I try to ask questions that will guide a way into their heads, I want to hear their experiences and pain points when they're trying to achieve something in life or business. This is a session with near-zero technical talk, so I prefer keeping the development personnel away from these discussions.
As the discussion goes on, I am documenting it (with consent) into notes and video-/audio tapes, which can then be later processed into problem statements, storyboards, user journeys, user personas, and so on. At this stage of the project, the goal is to have a humane conversation with the user, and truly understand what could make their life easier, or even delightful.
A paper notebook is my go-to tool at this point, and the most important skill to have is empathy.
2.) Define
When the meetings are over and the tea cups are empty, my desktop is filled with notes, recordings, drawings, sketches, and confusing corporate documents, not to mention all the information sitting in my head. All this data needs to be processed and documented in a concise, anonymized, understandable way because otherwise, I would forget almost everything before the day is over. All of it needs to be shareable with colleagues too. Epics and tasks in a project management system work great for this, fragmented chat messages (Slack) - not so much.
For documentation, I like to use the following templates:
🪪 User Persona Cards
After interviewing a bunch of people, I need to reference them later on during the project, but, it's not ethical to use their real names, faces, or direct descriptions. Instead, I can turn all that information into user persona cards, where fictional characters portray the essence of a group. Then these fictional characters (that seem like real people) can be referenced freely around the company, all the designers and developers can now remember who are the people we're trying to serve, at any point in the process.
🗺️ User Journey Cards
So, when I've collected the qualities and properties, needs and wants, pain points, and frustrations, I could really use a document that illustrates the actual path of how those users progress from point A to point B. User Journey Cards help me to map out where all these specific pain points occur in the process and where the potential for improvement lies.
📃 Problem Statement Cards
I see this piece of paper as the most important document. If you skip everything else, create this. The point of this document is to squeeze the (core) problem into a single sentence, including the user's name, characteristics, need, and the reason why he/she needs it (insight). Then, if someone in the team questions the entire project, this paper acts as a reminder about what you're trying to solve.
An example problem statement could be:
"Lisa is a business administrator who needs an approachable web development course app because she wants to shift careers from business administration into web development."
3.) Ideate
By having all these documents, I seem to have a reasonable amount of understanding. Now I can begin to ideate around it. Sometimes I get writer's block and I'm unable to produce anything, then my favorite method is to shut off my computer and utilize an exercise called "The Crazy Eights" (*). It is an ideation exercise where you generate lots of ideas in a short amount of time, either alone or in a group. How it works is that you take a piece of paper, fold it into 8 pieces, then use 1 minute for each piece, while you're doing it, you shouldn't be caring too much about the results, the idea is to let your creativity flow as much as possible, no matter how silly the ideas are. This exercise can be done as many times as you want, after all, ideas are only ideas and they will vary in quality, the point is to take in all of those ideas and cherry-pick the best parts.
* There are also other exercises, but this one is my favorite.
4.) Wireframe
The concrete result of an ideation session is typically a pile of rough sketches and funny stick-men, something that isn't yet that presentable to anyone else besides your team. I usually take the drafts, highlight the interesting parts, and start drawing the first "official" wireframe on paper based on those highlights. I could also do this on a computer but I prefer avoiding computers in these first stages since they provide distraction and limitations that paper doesn't. You cannot bend your computer, slice it, or draw on it with a sharpie, well technically you can but what the heck.
When the first version is complete, I'll present it to my team. Sometimes I don't need to go any further than this to get a signal that this isn't going to be the right way of solving the problem, or that we're missing some crucial information and we need to go back to the beginning. It doesn't matter though, it's way cheaper here than realizing it in the midst of development, when there are a handful of programmers attached, thirsty for coding, and the marketing team has already pushed out promotional material into the wild about an upcoming revolutionary product.
5.) Prototype
As I have my wireframes as a reference in front of me, I'll open the computer. I can begin constructing an interactive digital prototype, consisting of type, placeholder elements, layout, interactions, transitions, and whatnot. I'll do this in Figma. It's going to be a clickable and pseudo-functional collection of pages, all the most important buttons will work allowing the user to navigate between the pages. It doesn't have any true intelligence built into it, but it looks and feels like a "real" product.
The goal is to have a prototype that includes the basic functionality, but not the final layers of polish. It is crucial to keep it lo-fi enough so the test users and stakeholders don't get too attached to the wrong things. The focus should be on usability, and benchmarking if the product is going in the right direction, not to have arguments about the color palette, the roundness of the containers, or how the logo looks on a page. I usually keep my lo-fi prototypes in black and white.
When the prototype is ready, it can be tested with real users.
6.) Testing
It is now time to take the prototype and find real users to test it out. But, before doing anything, it is wise to make a written plan for the testing event and its goals. Who will be the candidates? How many do we need? Where do they live? Are they in our target user group? Is this going to be hosted virtually? Who will host the test? Do we have key performance indicators to track? What are we going to test? What technology do we need? Do we need NDAs? What questions are we going to ask? How do we ask our questions without causing bias? How do we reward the test users?
When the plan is created, it can be executed.
When the event is held, and the results have been digested into themes and insights. The team can make a decision to progress or not to progress further into designing the final mockups.
7.) Mockup
Finally, after the user studies show a green light, the design can be taken to the finish lane. This is the part where I'll start shaping a color palette, I'll browse the limitations of the component libraries being used at the company (e.g. Material UI), I'll be following the brand book (...or make a task about creating one), I'll be building re-usable sticker sheets, making animations, picking icons, designing backgrounds, adjusting spacings, reading about Gestalt psychology, arguing with developers, and trying to stay inspired, often if I get stuck, I lay on the floor and stare at the roof, it helps.
This is where the grind (*) happens, but when it's done, the design can be ceremoniously handed to developers (often the developers have already seen it as a work-in-progress). In an ideal situation, developers have answers to all their questions, they can focus on developing, the marketing team has a clear picture of what is to come, users will be all happy and the company makes huge profits...
* I enjoy the grind.
8.) ...except
...things often go wrong. But as I've said earlier, the point of all this is to make your mistakes early. After the product is shipped, there is still a lot of work to be done. Iterating the existing product designs is what UX Designers do all the time, so making the designs as modular and repurposable as possible is what proves to be useful in the long run.
I hope this post explained well enough the main phases of being a UX Designer.
Comments