Steps to Design User Interface

I wish I had written the UX Handbook I wanted to a few years ago. It’s harder than I thought it would be. Anyway, here is an outline of how I would approach a section of the book. Steps to design something:

1. Research & Problem definition

This is not artwork. This is a user interface. Start with a clear understanding of the problem to be solved. Use my problem statement template to frame it. I can’t tell you the amount of designers I have mentored or managed over the years who skip this step. Obviously, to find any problem, you need to spend time with users. Don’t ask them what they want. Ask them to show you how they work. It’s your job to see the problem, not their job to tell you. Use your empathy and understanding of technology. Look for annoying and repetitive tasks. The best problem is something they just assume is impossible and you can make it possible. In this step, you would use personas to categorize different users.

A problem thoroughly understood is always fairly simple. Found your opinions on facts, not prejudices. We know too many things that are not true.

As quoted in Dynamic Work Simplification (1971) by W. Clements Zinck, p. 122

2. Find the Emotional Connection

Read Emotional Design by Don Norman. This step isn’t as complicated as you might seem. You don’t need to be an empath to do it, although that helps. Basically, you interview people with the problem in step 1 and look for how the problem statement connects with them on a personal level.

We are all human beings with emotions. When a printer doesn’t install correctly for an older person, it makes them feel stupid and small. When I introduce two friends, I feel nervous that I am bothering them, but also proud that I can connect two colleagues.

The emotional relationship marketers have with both web developers and sales people was the foundation of everything I designed at Marketo.

3. Catalog your UI Options

Finally! You can actually start designing. Don’t try and finish any particular design. You want to just list out the possibilities. You can do this in bullet form of even do quick designs of different approaches. There are not an infinite number of user interfaces for a given situation. If you try to list them out, you will likely run out of viable options pretty quickly.

Doing this helps narrow your efforts. Try and eliminate some options and pick out a few favorites. Then you should ask yourself why each design deserves to “win”. Usually, a particular option is better for scenario 1 and another option for scenario 2. This creates a great discussion about which scenario is more important, not which design is better.

User Interface hasn’t changed dramatically in the last 30 years. A button is still a button. However, don’t be limited by what is typical. Think about every possible approach including mobile, AR, VR, voice Interface, desktop, and even kiosk or POS device. As a designer, you need to stay aware of every interface possibility and pick the one that best matches the personas and the problem context.

4. Execute the Design

This is an iterative and fluid stage, but ultimately you are in your design tool making a user interface. Be collaborative while you do this. You want to co-design with all sorts of people, not just other designers. Get their fingerprints on the design early and often. Remember, your success will depend on other people accepting your design. It’s not enough to be right. You need to be persuasive.

5. Pre-Acceptance Meetings

At some point, you will have a design that you think solves the problem and has sufficient fingerprints on it. The next step is to meet with the stakeholders of the project, one-on-one, and go through the design with them.

Stakeholders are people who can cause trouble if they aren’t bought into the design. Every project has a different set of people, but it’s crucial to make sure not to miss critical people. Usually, ask the PM for the right list of people. A good set is between 3-10 people. More than 10 means that your organization is more bureaucratic and this step will take more time. Bottom line: If someone can veto the design, they need to be included.

It is possible that someone refuses to meet with you. This is a huge warning sign. Either they shouldn’t be a stakeholder, or they should be willing to spend time before the official acceptance to learn the details. Don’t let anyone off the hook. Either they spend time with you or they shouldn’t get a vote.

I understand this step can take a long time and you (the designer) will be bored going over the same details over and over. Just remember, “Being right is not enough.” The good news is that this process will almost always yield good details. People will mention edge cases or ask interesting questions. It will make your designs better. I sometimes refer to this process as “hardening the design” the way you might harden a steel sword at the blacksmith.

6. Acceptance Meetings

Its time for all that hard word in step 5 to pay off. You have the official group acceptance meeting. All of the stakeholders are there and you walk through the design. If you skip step 5, this meeting will be an absolute goat rodeo. It will be pure chaos with a million questions and objections. It will break your spirit and diminish your credibility. However, if you do step 5 properly, the meeting will go mostly smoothly.

In my experience, it takes three acceptance meetings to get final approval. The first one has 2-3 objections that need further design. The second has just one problem to work out. And the third is perfect. then you ask the million dollar question:

Do you take this design to be to have and to hold, from this day forward, for better, for worse, for richer, for poorer, in sickness and in health, until death do us part?

Design Acceptance Question

This is a great moment for the team. You are aligned. A ritual like this feels good and builds trust in the design team.

7. Changelog

(See more detail on changelogs)

A changelog is crucial to maintain alignment. Things always change. You can’t avoid it. No matter how perfect your design was, you missed some details. The purpose of the change log is to document new decisions and force people to re-accept the design. This kind of system avoids people saying “I was blindsided by that!”

Example Changelog

8. Shepherding the Execution

One might think the job of design is finished. Unfortunately, engineering needs guidance during the build process. They will run across super weird edge cases or other kinds of problems. It is still part of the design process to stay connected and make sure the little details get done right.

Engineers will often change the intended product without telling anyone. (ugh!) You need to be there every step of the way to make sure it stays on track. This also builds rapport and confidence in the design team.

9. Go to Market and Learn

Depending on the size of your organization, you may need to train support and technical documentation so they can do their jobs. You might even need to talk to beta customers or sales people. As a designer, don’t just assume you should only be in a design tool all day long and the PM handles the rest of the world.

During this period, you should be learning about how your design works in the real world. You should be monitoring usage with something like Pendo or Gainsight. You should monitor community forums relating to the feature. You should sit in on sales calls and see how it is pitched. The point is to learn about how your design is working, or not. Sometimes, you might realize you missed a feature or usability aspect. Sometimes, you might feel like you hit a homerun. Either way, you are going to learn about your design and improve your understanding.

Engineers and PMs respect people who know the details. Take good notes (and keep them). They will come in handy later. When you can reference specific customers, your peers will be more likely to support the changes you are proposing.

10. Go to Step 1

Every step here is beneficial. I know you don’t do all of them currently. However, skipping steps will have negative consequences. You might also shorten the steps, but those will also have problems. The key is to understand how deep to go in each step. There is an art to knowing when you have worked a step for long enough. If you spend too much time, your overall productivity will suffer. If you spend too little time, your design will be sub-optimal.

The beauty of these steps is that you continue to learn and go back to step one with new problems to solve.

Obviously, if this was a book, I would go into detail on every step. But alas, my fingers work well for blogging and not nearly as well for book writing. Maybe one day. Hopefully, these steps are helpful. Feel free to ask me questions.


Whatya think?