“We need to have a faster design process, let’s hire more!”

This thought is quite logical for many people, also for me at least until early 2018 when i faced the same challenge. Back then I was one of the leaders in a huge design team, around 130++ designers, at the one of the marketplace unicorn in Indonesia. We’re blessed with a large team, mature processes and well-defined tools to support our day to day design activities. These all thanks to our massive growth and supportive leadership from senior management to see that UX is very important for our business.

But, in reality I learnt, that growing size of a Design team does not directly match the pace of growthof the organization. With those numbers of Designers we still feel that we’re lacking in resources. We still tried to hire more to catch up with the growth of the business, until we saw that the numbers of team growth didn’t align with the speed of the design delivery. It’s very resonated with the old statement in agile development that nine women can’t deliver one baby in a month.

Seeing this happened, we did a lot of improvement on our design processes. From building a design system, standardizing design rituals, building DesignOps and all the cool stuff resulting in better and faster design processes. There are so many approaches that we tried, some succeeded, most of them failed, but we’re moving into the right direction with the iterative mindset. Yes! solving this also required us to do design thinking.

But I won’t share all that we did here (Whyyy???). It’s because when we shared this to other external design teams, we see that it can’t be 100% copied. Each team has their own specific challenges and limitations. We also got a lot of similar questions and kind of pessimistic nuances, like “We only have small team members”, “We didn’t have enough resources like you”, “Our management didn’t see UX is that important” and problems that we may not have faced before.

Is it true? Depends (common answers from experienced people, lol).

But I got some answers when leading the OVO design team in early 2019, with smaller team members, limited resources and other similar problems raised by my friends who were part of Startups. It’s about how to align the expectations of stakeholders and the design team about faster design processes. This very first step is important as a foundation of easy-to-follow question-based guidance that can be implemented on any size of design team.

Defining a mutual understanding of “Faster Design”.

The first important step is to define “What is Faster Design?”. Why we need a faster design and what impact that we want to pursue by having this. It will set a clear ground for everyone in defining the success. So far, I saw two common approaches when a team demands a faster design process.

1. Shoot as many as you can!

This approach demands the team to be faster in delivering many things and see which one works well. It can be products, features, UI and other things. Imagine you’re playing archery. This approach will push you to have as many arrows as possible and shoot it in a very fast way, then hoping that 1 of your arrows will hit the target. Same with the design process, this approach requires the design team to deliver as many products or features as possible to see which one is working.

2. Expand design to a broader scope.

This approach commonly happens when the organization becomes more mature in understanding the importance of design. There are more and more design activities happening, like user research, design workshops, design validation and so on. When everyone needs more design support, the current design resources are usually stretched. Back to the first couple of years in the 21st century, design might have been perceived as a beautifier of the visuals, but now design is an integral part of customer centricity in defining products and services to offer. One person can handle multiple projects at the same time that will impact the speed and also quality. Then, the organization will start to identify how to make a faster and more scalable design process. 

There are many other reasons why organizations require faster design processes other than the two above, like the growth of business, seeing better UX from competitors, slow design iteration and so on. There’s no right and wrong in defining “faster design”. The most important thing is to align with the stakeholders, what is the expected outcomes from this “faster design”. By understanding that, the design team can make appropriate strategies to achieve that.

Along my 8 years journey (since 2012) in digital product design and development, I faced this problem multiple times. With all the design iterations that I did, I found a good and bad thing in solving this. The bad thing is, there’s no silver bullet to solve it. Every organization has their own specific problems, needs, maturity and even the success definition of “faster design”. We can’t generalize the problem or address it with a single solution. But fortunately, I observed a pattern that can be used as a guidance and principle in achieving a “faster design” through efficient product design by making time for what matters.

No silver bullet! Only 4 Key Questions..

To have a fast and efficient design process, we need to make sure that we’re solving the right problem before aim to solve it in the right way. Whatever definition that we have for “faster design”, we need to understand this principle first. In product design, it is commonly seen that there are several processes before the actual design crafting or development. Things like user research, industry learning or field observation happened to get more understanding about the real problem to solve. With limited resources, how can we do this in an efficient way?

As expressed earlier in this article, there is no silver bullet. Each organization has their own specific challenges. I found 4 Key Questions that need to be answered, to have an efficient design process. These 4 key questions are generic, but without clear answers on each of the design phases, we will hardly design in an efficient way.

1. What people’s problems are we trying to solve?

   
   Usually, when we have initial discussion for a design project, people will share problems or hypotheses that they have, like:

• Our adoption rate for this feature is very low. We need to improve it by doing X.
• Our payment transaction is lower than usual these last 2 weeks.
• Let’s build this feature to improve our monthly active users.

All of the above are not people problems. It’s a business or even product problems that we have internally. To produce an impactful design, we need to dig deeper and find the people’s problems. It will be the foundation or root cause that needs to be solved.

For example, low adoption rate means that people are either not interested to use it or even didn’t discover the offer. Why? No value for them? Not solving any of their pain or giving them gain? And all the analysis that you should do. We need to find the “why” from the people or users itself to solve that problem.

Characteristics of people problems are:

• Human Centered – which means things that happened to the human/people/users directly. Put aside first all the business metrics and internal numbers that we have. Find the real problem that happened to the human.
• Solution Agnostic – don’t start with a solution statement, like let’s build this or that. Usually people who have rough ideas and too early fall in love with them will be dragged into this. Make sure that we have a clear statement of the people’s problems first.
• “Your company”-wins Agnostic – don’t even think how we can solve and get benefit from it at this stage. For example, when we see people have problems with something, we directly think how we, as a company, can offer them solutions. Get a strong understanding first.

Here’s an example of people’s problem that we identified at OVO payment flow, when we improve the rewards transparency for the users, before the transactions, with clear messaging.

Above is our checkout screen page, where users can choose the payment method that they want to use. Each payment method will have some rewards (cashback) based on some terms and conditions. We see that people often didn’t get the cashback as expected because of the rules, like limit, maximum cashback or the period. From that condition, the people problem that we set is “People are disappointed when they don’t earn cashback as expected”.

As you see, it mentions problems faced by the users, the human itself. No business metrics or internal numbers yet. No solution statement yet. It clearly states what people’s problem that happened. In this case study, it becomes the initial statement until we design the cashback estimation feature (the green one) that shows estimated cashback that our users will earn. Sometimes, you can easily reframe the initial statement that you have by analyzing your data or you have to do deeper user research to find it. 

To do this, I pushed design involvement at the very early process at my organization when we identified the problem and opportunity. My user research team will help to define this people problem. Also, we worked with our data team to build engines that gather customer voice across channels that we have, like social media, customer support, app/play store reviews, etc. These will help us find the real problem faced by our users.

Whatever approach that you want to do, find the most efficient way to define the problem in terms of user problem. Agree with the team for it, including your design team and the stakeholders, then you can continue to the next question.

2. How do we know if it’s a real problem & worth to solve?

After having a clear people problem statement, the next is to know if it’s real and worth to be solved. We have limited resources and there are so many problems in this world. We should address problems that we really want to solve, with an impact that we want to have, for example the improvement on some metrics, such as click through rate (CTR), conversion rate (CVR), total purchase volume (TPV), satisfaction rate, NPS and so on.

The first thing to do is to find quantitative and/or qualitative evidence. You can grab the data from your analytics or do specific user research for it. The mindset should be using the right methods to answer the right research questions. One of my favorites is Nielsen Norman Group’s explanation about When to Use Which User-Experience Research Methods. The key is to find the quickest and cheapest way to answer the research question in a valid way with a confident level that your team’s agreed on. Don’t worry, there’s always a trade-off between more time needed for research and time to market expectation. Adjust with your specific cases.

After getting the evidence, you should know whether this problem is real or not. Then, the next question is the worthiness for us to solve this. We need to define the success metrics with a specific target/estimation. Here, we need strong collaboration in aligning user metrics, product metrics and business metrics. For example, if we find a user’s confusion in doing things in our product, we should translate it to things that matter for the other team like drop in the funnel for the product team or even increased cost or reduced revenue for the business team. Here’s an example at OVO.

With this approach, we will know the worthiness of solving the problem from multiple perspectives. Remember that being efficient is solving the right problem. Usually we will compare the answers of these 2 initial questions for our problems and decide which one to go next.

3. What are the AH-HA! Ideas?

With clear customer problems to be solved and enough evidence, we can start the exciting part which is ideation. The goal is to find beyond obvious ideas to solve the problem. One of the important aspects here is getting multiple perspectives from multiple teams to reduce bias while also encouraging new point of view in solving the problem. We should use our divergent thinking in our cross-team ideation workshop. Encourage and record all the ideas, as long as it has clear objectives and strong design intention in solving the problem. Another critical mindset is to think beyond product. Sometimes, the solution is not mainly driven by product. It can be a process, service, partnership or other improvement area.

One of my favorite workshops is the Whiteboarding session. Here, we as a cross functional team, work together from identifying who are the users, their goals, their journey, pain or gain point on each step inside the journey, all the constraints that we have until ideas, validation and trade-offs that we need to make. As you see, we push customer understanding at the early step in order to bring more customer centricity on every decision that we make. Every thought should have strong intentionality to solve customer problems.

You can choose whatever methods that work in your organization. The key here is to think divergently with different teams to produce beyond obvious ideas with strong intentionality. Always make sure that every thought, analysis and decision should aim to solve customer problems first.

4. How do we learn and choose the best ideas?

Answering the 3rd question above will give us many ideas to experiment. The word “experiment” here is very important. The foundation of ideas is hypothesis, which need to be validated or answered through experimentation. On every idea that we have, define how we can validate and learn in order to choose the best ideas. The mentality is to iterate as fast as possible, with quickest & cheapest way to validate. There are 2 common things to support this, which are Quick and cheap prototype and Modular elements.

Quick and cheap prototypes help us to do behavioral validation, which is the most common validation in user experience, where we try to observe what people do in reality either with or without controlled variables, like new design prototype, new process and other validation control.

One of the examples is when we’re exploring the best way to give cashback rewards to our users. As the cashless payment industry becomes more mature, each digital payment player is reducing their cashback which initially acted as a trigger for users to try. Along the time, users already see the other benefit of cashless, like practicality, no need to find exchange for the cash returned, easily track their spending and so on. To stay competitive as the industry leader, we experiment to keep users transacting in our platform by answering whether users prefer smaller fixed cashbacks or randomized with the opportunity to earn bigger.

This is a behavioral question, and in order to validate it in a fast way, we did role-play by mimicking real transactions with real users, and offer them to choose the cashback that they want to earn, either a smaller fixed cashback or randomized to earn bigger by playing a roulette game. We learned quickly although humans are risk-averse, but for rewards they love the opportunity to earn the bigger one. With this quick learn, we successfully launched randomized cashback as the new mechanism and users still love to transact in our platform, compared to competitors.

Another important thing is modular elements in our app architecture. The key to be efficient in learning is the power to experiment and change quickly based on the insights. We build all of our new pages in a modular way, where its section can be configured easily through the backend without the need to release a new app version. In the mid to long term, we also aim to level it up to personalized content based on user behavior to bring the best relevancy to the users.

As you see, the mechanics to learn and choose the best ideas in an efficient way can be done very quickly with low effort through quick and cheap prototype / testing mechanics. Put aside the need to develop the product directly. Designing a product is a learning process to find the product market fit. Moving there as quickly as possible with creative experimentation is the key to an efficient design process.

Be efficient to be faster in bringing impactful design

All 4 key questions above are the minimum questions to be answered in each of your product design cycles. You can add more if needed based on your organization needs. But from my experience, having those 4 be answered clearly will help us to be efficient. Not only in the process but also in achieving the outcomes.

With these, we can always make time for what matters in our design process, despite the limitations that we have. No matter what is the foundational reason from your company to ask a faster design process, always anchor the mentality to the impactful design. It’s because design is not measured by how fast you produce many design, but how impactful your design is to achieve the goal.

“Efficient is understanding the right problem to be solved, and embracing failure to solve it iteratively”.