Why we choose to fail early for UX

Yvonne Chia
Government Digital Services, Singapore
4 min readSep 14, 2017

Ever had a stakeholder who wanted A but his boss wanted B and his boss wanted C?

Then after months or even years of working on it, you launch the product only to realise that what the market wanted, was actually D.

Stakeholder wants vs market needs

Therein lies the pitfalls of the Big Design Up Front approach, where the aim is usually to complete and perfect the design of a product before implementation. However, internal decision making often results in lengthy rounds of design cycles, thereby prolonging the time that it takes to get to market.

Which means that you could miss windows of opportunity, or encounter a change in market needs by the time the product actually launches. All the blood, sweet and tears that were invested could just be a terrible waste of time and effort.

Fail early learn quickly

Lean UX, on the other hand, focuses on getting feedback early to make quick decisions. It borrows from the build-measure-learn feedback loop of the Lean Startup methodology. With this objective in mind, it’s extremely crucial that we don’t let ‘perfect’ get in the way of ‘good enough’.

Even Ernest Hemingway knew that

The minimum viable product or MVP is meant to begin the process of learning as quickly as possible. This is why the MVP has also been referred to as the SFD, or ‘shitty first draft’ — because subsequent iterations will always be attempts to improve previous versions.

Reducing risk reduces waste

The longer you wait to involve the team or users, the riskier your assumptions become. Just think about it — without validating your hypotheses, you are essentially building assumption upon assumption. By iterating on solutions frequently, we reduce wastage, so that we do not work blindly on things that are not used in the final product.

Managing uncertainties in agile development

That’s precisely why agile principles advocate maximising the amount of work not done. Similarly, lean principles recommend deferring design decisions till the last possible moment. That’s not to say that lean is lazy. It is a direction to reduce unnecessary time spent on design, while prioritising efforts on more important user needs.

Constant work in progress

This iterative process was what led the Business Grant Portal, or BGP, to achieve a satisfaction rating of 84% and above. An impressive result for sure, which wasn’t achieved in a blink of an eye. In fact, it took more than two years to get here.

In one of the iterations, a key learning was discovered — that users found it much easier to look at the grant application process in stages. The information was then reorganised to improve the overall user experience. Had we chosen to drum up the design process from the start, we would have seen a huge amount of man hours go down the drain.

BGP Gen 0
BGP Gen 1
BGP Gen 2
BGP Gen 3

Even today, the team is further refining BGP with new features. Rather than designing for a big bang, we make it a conscious effort to set our sights further. Since aiming for a high level of fidelity before going to market can be a rather inefficient approach, it’s better to look at it in terms of a journey.

As issues surface and more fixing is done, the more we can ensure that we are building the right thing for the right audience. And efforts to polish the product will deliver more value as the journey progresses.

How does your organisation work iteratively on design? Leave us a comment to share your process.

--

--