How I work?
Here’s how I roll as a UX'er with the goal of producing good user experiences—whatever the end result may be (app, website, image, jingle, etc.)
Please note, not every project follows the same linear path due to time-, money-, or people-related constraints, but typically my work flow uses "design thinking" as a guideline.
1.) Empathize
My goal is to solve the problems of the users, either from the get-go when building new or afterward when something old needs to be fixed 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 single note of music is added to a piano roll, or a single pixel on a screen is being placed; a good user experience can very rarely be baked in as an afterthought.
The main idea is to fail fast and avoid sinking my feet too far inside the technicalities while not understanding what I'm trying to solve.
After the project has been outlined into tickets, the work typically begins by having discussions with the users and/or stakeholders, either virtually or face-to-face. In these discussions, I'll try to ask questions that show me a way into their heads. I want to hear about their experiences and pain points when they're trying to achieve something in life, passion, or business. This is a session with near-zero technical talk, so I prefer keeping the developer mind-set at bay 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, and user personas. At this stage of the project, the goal is just to have a conversation with the user, feel empathy, and see what could make their life easier or even delightful.
📝 A paper notebook is my go-to tool at this point.
2.) Define
When the meetings are over and the tea cups are empty, my desktop is filled with notes, recordings, sketches, and confusing documents—not to mention all the information sitting in my head. All this data needs to be processed and documented in a concise, anonymized, and understandable way. Otherwise, I would forget almost everything before the day is over. All of this needs to be shareable with colleagues, no matter if they're remote or on-site. Epics and tasks in project management systems work great for these 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. However, it's not ethical to use their real names, faces, and/or direct answers. Instead, what I can do is turn all that information into user persona cards, where fictional characters portray the essence of a group. Then these personas (that seem like real people) can be freely referenced around the company, and all the designers and developers can now remember who the people are they're trying to serve at any point in the project.
🗺️ User Journey Cards
When I've collected the qualities, properties, needs, wants, pain points, and frustrations of the users, I could really use a document that illustrates the concrete user path from point A to point B. User Journey Cards work great for this; I use them to map out where all these specific pain points occur in the
user path and where the potential for improvement lies.
📃 Problem Statement Cards
I see this piece of paper as the most important document in a project. If you skip everything else, produce 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 or 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 of a 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, so 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, and 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 figures—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 or Sketch. 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 low-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 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 start 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 true 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.
*In a situation where there are no dedicated developers around, I'll take the designs and start turning them into code, along with implementing the required accessibility requirements. My educational background is in software engineering, but that's a whole different post.
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 designs is what this is all about, so making the designs as modular and repurposable as possible is what proves to be useful in the long run.
- - - - - - - - - - - - - - -
