Channels ▼


Lean UX: Making Sure You're Building the Right Product

If you're in the business of commercial software development like I am, then I presume you make software because you hope someone will try it, buy it, and find it useful. I further presume that after many users click that "buy" button on your product, you'll start feeling the product is a success. What does it take to get users to click that button? Answering this question is actually more important than building an incredibly sophisticated, intuitive (insert 20 glorious characteristics for) software product. With all the best intentions of their makers, many products will still fail, simply because their makers didn't fully grasp for whom they were making the product, what it was needed for, and what motivated the users.

Successful software products can result from following the design philosophy of Lean UX. This approach requires teamwork with users in collaboration about deliverables, processes, and rules.

Lean UX Is for UX What Agile Is for Developers

At its core, Lean UX is a mind shift in design philosophy that advocates shared understanding between organizations. A key principle of Lean UX is continuous discovery, which encourages customer engagement during the design and development phases — visiting users and learning what they plan to do with your product.

This research into your users' behavior helps create personas, which provide deep insights into user needs. And it validates the product strategy and design. 

Unfortunately, many companies using agile methods don't invest in this kind of user research or in a UX strategy because they don't think they have the time to do so. Often, they believe they already know enough about their users. This is rarely the case.

Although the quality of the research improves with the frequency of meetings, the number of team members involved, and the breadth of the roles involved, any amount of research tends to uncover fresh revelations.

Because developers typically spend months, sometimes years, developing a software product, investing in research to understand customers is not only worthwhile, but essential. Such research doesn't have to take years or months. It can be done in as little as two weeks, during sprint 0.

Make Software for the "U" in UX

More important than, "Why do we make software?" is the question, "Whom do we make software for?" Unless we know who the users are, we're flying blind. The sooner we start user research to determine their needs and goals, the closer we'll be to understanding what they want.

User research has two key steps:

  • Creating personas: Personas are profiles representing the needs, behaviors, goals, skills, attitudes, and personal characteristics of a user or group of users. Techniques for building personas vary from quick guerilla research to elaborate studies of individual users. 
  • Sharing the results: Everyone on the software development team should have a common understanding of what the end users care about and what they need. Customer personas should be disseminated to the whole team and discussed in depth to ensure cohesion.

In Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf and Josh Seiden sum up the situation elegantly:

"Why do it? Ultimately, the success or failure of your product isn't the team's decision — it's the customers'. They will have to click that 'Buy Now' button you designed. The sooner you give them a voice, the sooner you'll learn whether you've got an idea that's ready to be built."

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.