As a designer you need to get your process straight. And we’re gonna be real honest with you. We needed some time to get ours on the right track. We took some nasty humps to get where we are today and we know we ain’t there just yet. As we see it, our process never stops evolving. Fellow designers show us new methods everyday, we try new things that turn out really well and sometimes we try new things that turn out just bad. Our process grows nonetheless and we love that.

We also love to share. Let’s give you a little guided tour through our kitchen, shall we? We would kill to hear your tips on fine-tuning our recipes.

There’s no one-size-fits-all

Before we start, we need to get something off our chests. What you’re about to read is not some ideal go-to for your next design challenge. It’s not even our own go-to. Every project needs it’s own kind of methods. Sometimes we feel like we need to talk to many users and stick several customer journeys to the wall. But there are also a lot of cases where we put in branding & UI methods at the center of our attention. Pick the methods that suit the project best, while taking context, available budget, opportunities and team experience in account.

Research

Research can be tricky. It’s time-consuming and it’s easy to get lost in an endless loop of hypothesis, tests and refinements. We believe at least some time should be invested in the research phase, because it’s important to know what you’re designing, whom you’re designing it for and most importantly; why you’re designing it. These research methods provide answers to these questions.

“Life’s too short to build something no one wants.” — Ash Maurya

Desk Research

Desk research sounds lame and it often is. There’s no better way to build up momentum, though. As a product designer you’re dealing with versatile subjects. These subjects can be very complicated. It’s insane how often rules and data are involved with insurances, rentals, hotel bookings, funding and banking. Not even mentioning the brand of the client. Reading reports and looking into researched data gives intel about the subject and helps to understand the client better, which answers many questions early on and hopefully rises more and more questions to dive further into.

Interviews

Talking to users can be valuable — even though users don’t always say what they think. But in many cases interviews can help you capture stories, experiences, feedback and emotion if done right. Conducting a good interview requires some skill and preparation, but you will learn to get useful insights by asking the right questions soon enough. For the sake of planning and budget, think about whether interviews are going to provide you enough information for your cause. For smaller projects there’s often no budget or time in the first place or it’s hard to get in touch with the right amount of users.

Wall of Assumptions & Insights

Everything we learn gets documented and sticked on a wall. Making insights tangible is an important part of the research phase. It’s much like crime-solving, really. By having every relevant aspect of your case on a wall, you’ll be able to establish links very easily. It gets you to your “Aha-Erlebnis”, which is the start of your actual problem-solving. On our wall we make a difference between insights and assumptions. In the early phase of design, it’s not bad at all to work with just the latter. Sometimes it’s more important to actually get started and play with the problem and solution early on. Use the wall as a guide to verify hypotheses later in the process.

Personas

Since you put so much focus on the user as a UX Designer, you’d want to work with personas. Especially if you find out you have different types of user segments to begin with, it would be wise to compose these. Along with customer journeys it will give direction to flows and to the overall design. Personas get better and more spot-on when you receive new insights about the user. When you ‘test’ your persona on the design, it might be the case that the design needs some alteration as well.

Customer Journey

The customer journey makes it clear what path the consumer usually takes during their total experience of the product and brand. By defining all the touchpoints, mapping the according emotions, highlights and opportunities, it becomes clear what the experience looks like.

Sometimes its useful to compose two different journeys; one for the current situation and one for the preferable (future) situation. The future situation should almost only contain highlights and can be used to give a direction to concept and even the design of the product. Just like the previous method, the journey is often based on hypotheses in the beginning, which isn’t bad because it gives the team a starting point.

Concept

Rainbows, lollipops & unicorns. Welcome to the concept phase called Fantasyland. It’s where dreams are in the lead. And be sure to dream big.

No really, in this phase it’s the designer’s job to take the team by the hand and discover what’s possible. It’s ok to think outside of boxes, but be sure to have both feet on the ground eventually. You’ll need a solution that will actually work in the end. Make use of the methods below and don’t forget to have fun.

Product Roadmap

A product roadmap helps to understand all the elements of the product the team is building and makes abstract ideas a little bit more tangible. The product roadmap serves to get the team, especially when collaborating with clients, on the same page and get the product’s general planning on paper. Often the client already knows a lot about the subject and the requirements for his product. This map helps to document their mind and reform it into usable and actionable design goals. We use Roman Pichler’s GO Product Roadmap and alter it a bit to get all the elements we want to make it more suitable for concepting. (Date, name, goals, features, metrics, stakeholders & inspiration).

Brainstorms & Sketching

There are thousand and one ways to organize successful brainstorms. We like doing them, because brainstorm sessions get individual thoughts into the group. The best ideas are born here and everyone will embrace them, because it’s a team effort. Our collaborative sketching session starts with a stated frame, which describes the challenge and problem the team is trying to solve. After that, we start sketching individually. Everyone is asked to sketch four or more solutions on a sheet of paper. Then we discuss those, share insights, and start another round. This last set of ideas is more detailed and shows some more similarities. We round up by writing down what the take-aways (and design guidelines) are for that design problem.

Sketchboards

A few days later we pick up the brainstorm again and start building our concept wall. All of us deliver more detailed sketches, which will be the cornerstone of the first wireframes. We use the sketchboarding techniquefor this, which basically are templates for low-fi wireframes. Occasionaly, when we start building a new section of the product, we go back to our brainstorm table and repeat the exercise.

Interaction

We hate to draw a line between interaction and design, because we like to place these side by side, instead of one after the other. We can explain the activities for interaction and the activities for design better if we make this diversion for now, however. Anyway, this phase is all about finding solutions and thinking of ways to get them in the design.

UX Board

It often begins with a collection of examples. We collect screens, flows and micro-interactions we like and are relevant to our case. Of course the board’s focus is completely on interaction. Its purpose is to get off to a flying start; it prevents us from reinventing the wheel or making us realize we need to invent an even better wheel.

Flowchart

For complicated flows a flowchart provides a solution. It helps define the actions required in the flow and what all the possible follow-up actions can be. There are several ways to create such a flowchart, but we like working with flowchart cards the most.

Wireframes

We know. Wireframes can be bad in the process. It can kill creativity. And even though they’re easier to create than mockups, they are not presentable to clients. They don’t come close enough to the end result and you don’t want to provoke false expectations. We do use them nonetheless. Not because we’re stubborn, but because we know how and when to get value from them. We like sketching a lot, but for screens that heavily depend on interaction, hierarchy and flows, we (also) make wireframes. And when we make them, we make sure they are detailed enough to see what goes where, yet abstract enough to not imply visual details.

Design

The design, of course, is what actually gets delivered. Clients look forward to this one. This is what the product is gonna look like in the end. Well, what it should look like at least.

Brand Analysis

First we check with the client what they like and dislike about the current branding, if available. Then we analyze the branding ourselves and determine what we are going to reuse, improve and what we’re scratching out.

Moodboard

From examples the clients show us and mostly from examples we feel is the right direction for the overall design, we create one or a few moodboards. The moodboards represent a different style we feel like is worth to pursue.

Styleguide

Once a style has been picked by the team, it’s time to further explore and define it. A styleguide helps to get the UI essentials out pretty quick. As you can imagine, Sketch’ symbols do wonders in this part. Troubles setting the styleguide up? It might help to just start with the actual design and play a bit around with your interface. Remember this: your styleguide is a set of guidelines. If it needs alterations or diversion, don’t be too shy.

Design Mockups

Then the actual magic happens. As you can see the design enhances the user experience which is initiated at the earlier sketches of wireframe by using typography, color, icons and other elements.

Reviewing the Work

Giving and receiving feedback is an art form. Designs need to be reviewed, preferably by at least a few members of the team. Not all feedback is valuable (and some feedback not at all), but it always gives new insights or validation. All remarks let you rethink and revaluate your choices, which can’t ever be a bad thing, even if you deliberately don’t change a single pixel in your design afterwards.

Developer Gatherings

Developers and designers. They need each other. So please, work together. Get input from each other early in the process, make developers part of brainstorms for example. Together you can come up with something that looks good, works well and is feasible. Also be sure to have plenty of interaction when the dev is actually working on the product. Discuss how things should work exactly, clarify design (decisions), provide the states that were forgotten about and check if the colors and pixels are implemented the way they were intended.

Let’s share recipes!

As we said before, plan methods accordingly. If the budget is limited, be creative and think of time-saving ways to get the needed data. Sometimes there’s no time to do interviews and make flowcharts, it’s not always the right project to do everything. Pick the essential methods that enable you to gather enough intel, come up with good solutions and deliver a phenomenal design.

We’d love to elaborate on the whens and hows some more, but let’s save that for another time. We mostly are dying to hear about the methods you like to work with and can’t wait to give those a spin!