Real life case

So you’ve done some great design.

You organized a review meeting and invited a group of people.

You opened your Figma design and started to show your gorgeous design to the team.

Then you started to get subjective feedbacks like below

And you are stuck, not sure what to do next.

What is the problem?

The problem is that people tend to forget what the problem is. Often times we are spending too much time on the solutions, and distracted ourselves from solving the real problem behind it.

What is the problem are you trying to solve?

To my surprise, this was such a difficult question that very few people can really answer it properly.

In order to make things easier, I created some patterns that everyone can follow and thus sort out the right problems to solve.

Starting with the basics

WHY

As a product designer, one thing that you shouldn’t forget to do is always asking WHY.

• Why are we doing this?
• Why are we doing this now?
• Why this is so important?

These are not scientific questions that take months to sort out, sometimes it is simply because of “my boss really wants this happen”, which happens in every company.

In the case that it is really because your boss required this, it is still your job to figure out why he wanted this. Stop complaining that “my boss doesn’t know how product design works”, try to figure out the real needs behind the surface.

Anything that helps you to do your job, is part of your job

It is important to understand the WHY correctly because all the following WHO, WHAT and HOW, would be depended on this.

You can of cause have multiple reasons why do we want to do this. But it is also important that you have set the priority right and stay focus on the most important ones.

Most importantly, do NOT include a solution in your problem statement.

Now that you’ve got the WHY, it is time to figure out the WHO and WHAT

WHO

• WHO’s problem are you trying to solve?

Usually, WHO is (a certain group of) your users, sometimes it could also be an internal team, the whole company, or yourself - don’t feel ashamed to put you or your team as the WHO, as long as it does make sense.

In this sample, since we are talking about how student who is trying to find a teacher through search, our major target audience would be first time users, as well as existing students who haven’t found a teacher they want to regularly take lessons with yet.

On the other hand, teachers may also have the demand to display their most valuable information in the search list, so that they can get more students.

Now do we want to address both student and teacher’s needs? Since in our WHY, it states that the students are having trouble finding the proper teacher, the student’s need should be our priority to solve. Teacher probably could also benefit from whatever our final solution is, but it is NOT our main task to do.

Hint: if you realize that on the teacher side there are really bigger issues to be solved, you should go back and update your WHY instead.

So now we are clear that our WHO is students who are searching for a teacher

WHAT

• What goals do you want to achieve?

There are two parts of this, one is linked to your WHO, as we’ve set our WHO as students, what do we want to enable them to do?

In this case, a possible WHAT is for students to be able to get necessary information while searching, so that they know which teachers to click to check their full profile.

Another part is about business goals, like traffics, conversion rates, purchasing numbers, etc. How much measurable improvements do we expect to get?

In this case, as the platform, we certainly wants students to book teachers the sooner the better. However for a long-term goal, we want students to find the RIGHT teachers for them, so that we would be happy about the learning experience and would come back later. So our goal here is not about getting the purchasing as soon as possible, instead it should be helping the students to get the right information so that they can find the right teacher as soon as possible.

Product design starts here

Now that we figured out the basics, it is time to go to the design phase. I break it down into 4 different stages.

1. User Goals

I’m using the Hills concept from IBM Design Thinking framework to define the user goals. Writing hills sometimes could be tricky, but since we have already figured out the WHY WHO WHAT questions, we are almost there.

In the Hills format, we define the user goals in three aspects: WHO WHAT and WOW.

We already have the WHO and WHAT there and we can already start to work on the solution. Setting the WOW moment is harder, but having it there helps us to push ourselves to be more creative and innovative.

The WOW moment is basically your competitive differentiation, or how you would delight users during the experience.

You can set multiple Hills per project, just make sure to set right priorities.

Cheat sheet: You can always come back and modify the hills (but not too much/often)

2. Define User Journey

If it is an update of existing feature, usually we can have two user journey maps, the current journey and the tobe journey.

With that we can already start the necessary review/discussion, before any heavy works have even started — this is also surprisingly important because often times we realize something has to be changed but the development is almost done. We ended up either delay the release or live with the glitches.

3. Flow Design

This step should be pretty straight forward. It is basically transforming the flowchart from the previous step into UX wireframes, add all necessary logics and interaction annotations.

4. Final Visual

The final visual is not a standalone image design. It embeds into the flow from the last step. We can leave unchanged pages in wireframe state, so that the audiences can focus on the most important ones.

There are of course a lot more details to be covered in the final visual design. We need to make sure all the design system components are properly used, the frame/group structures are properly setup so that it can be consumed by the development team, etc. That could be another big topic talk about in another session. We are not going into all the details today.

Now, are we achieving our goals?

What’s important during the whole design process, is for the team to come back to the Hills from time to time, to verify whether we are achieving our original goals.

Sometimes it could be difficult to validate the impact of the design, and we have to release it first and then get the data to support our hypothesis. It is also fine to make mistakes, just make sure that we all leant from the failure and grow up in the future.

Hint: in this real-life example, we made both UI and algorithm changes. I wasn’t totally convinced by the design solution at the beginning, but the AB test did show that the UI iteration made users request lessons and initiate booking faster, while there were no statistically significant changes caused by new algorithm.

“Hmm.. do we have to go through all the trouble EVERY TIME?”

It is ALWAYS a challenge when pushing things forward, to get people aligned on the process and follow with it.

The tip is to start things piece by piece, make small, but valuable samples for the team to start seeing the values.

Start with asking the WHY WHO WHAT questions, because it is really the basic basics. Move on to the WOW moments whenever possible.

Call retrospectives to reflect what we have learnt from the past experience, adjust and iterate for future improvements.

Aesthetic, Empathetic and Creative

At italki, we believe that good design is Aesthetic, Empathetic and Creative. Our vision is to build beautiful, intuitive and exciting products.

In this practice, we are focusing more on the Empathetic part by better understanding the problems and user goals to achieve, and push a little bit to the creative part by integrating the WOW moments.