Offshoring & Outsourcing

Building the Scientific Method into User Experience Design

  • author image

When you think of User Experience (UX) Design, do you associate it more closely with an art studio or bioscience laboratory?  Pixel pushing or strategic, quantitative research? If you are like most people, it is the former.

However, for a significant UX investment to make sense, there needs to be more science along with the art.

Traditional UX design 

Part of the reason for the perception of UX as art is the methodology of “traditional” UX design. A UX designer begins with research to understand the customer and stakeholders. Based on this they define the product, develop a flow and create a visual design. A developer then codes it and the client releases it to market.

It is a linear approach with two implicit assumptions:

  1. The UX designer (or the client) knows the customer problem and the application features that solve it.
  2. The end product is a set of polished deliverables — the wireframes, flow diagrams, mockups, documentation, code snippets etc.  These are how a designer gets compensated and consequently what a designer is motivated to “sell” as solutions to the stakeholders. The design process that creates these remains a black box. 

Scientific method

The “traditional” UX approach and the assumptions are distinctly different from the methodology used in scientific / applied research and product development. The hallmark of the scientific method is a rigorous focus on hypothesis, process transparency and test cycles:

  1. Define a question or problem
  2. Develop a hypothesis to address the problem
  3. Test the hypothesis empirically and analyze / share results
  4. Draw conclusions and change variables to refine hypothesis
  5. Repeat steps 2-4 until you have a validated idea 

Lean/Agile UX design methodology

User experience design methodologies are changing, and it is for the better. Catalyst for example, mixes up the traditional way of designing UX by incorporating Lean and Agile methodologies that mirror the scientific method. This approach changes the linear path of define, design and build into an iterative set of collaborate, design, prototype, test and validate cycles. In a very real sense, we demystify the design process (just as the scientific method demystifies natural phenomena). 

Agile

Agile is Catalyst’s preferred release methodology. It is all about collaboration and short product development cycles. Percolate up the most important things to get done and then release early and often. But how do you know that there is any value or even a market for the product you are doing such a good job releasing early and often? 

Lean

That’s where Lean comes in. Lean is all about experimentation, direct observation and user validation. Start with a hypothesis about your customers, the jobs they want to do, what they are willing to pay for, etc.  Then test externally (i.e., not just with your own design team), using anything from low-fidelity sketches to code prototypes. Rinse and repeat.

At each cycle (sprint) you produce the minimum feature set (sketch, prototype or mockup) needed to test out the critical components of an experience (i.e., your hypothesis) using real users. This testing lets you refine the ideas, and the cycle repeats.

The tighter the cycles and the greater the amount of feedback (from team, stakeholders, customers), the less time you spend refining a wrong solution and the more time you spend honing a validated hypotheses/user experience and reducing project uncertainty.  

Deliverables:  validated user experience

With Lean, the deliverables along the way are not traditional, nicely formatted wireframes, flow diagrams, mockups, documentation, and code snippets. We don’t assume in advance that we know the answers and can deliver final products without testing. Instead deliverables stay very light, editable and testable — just enough to get feedback from real customers and validate (or disprove) direction. We do not try to validate the whole piece of software from the start.  We just test a specific hypothesis.

This Lean+Agile approach is a paradigm shift for many clients who are used to designers “doing their magic” and coming back with something they sign off on (or reject).  But once they understand the process, our clients embrace the transparency of the design process and the empirical validation and quality of the end-result software. 

Putting it all together

Lean, Agile and the scientific method aren’t the whole picture on how to create great software applications. Great design is still great design. Creativity and innovation are still creativity and innovation. You still need personas, usage scenarios, mental models, etc.  But building the scientific method into user experience design means these are all testable and refinable components, just like anything else.

Paul Giurata is the managing partner for Catalyst Resources, a user experience and application design firm headquartered in Silicon Valley. He and his teams have worked on more than 450 software projects in Financial Services, SaaS, Life Sciences / Biotech and mission-critical systems.  For more information, contact [email protected].

Post Your Comment




Leave another comment.

In order to post a comment, you must complete the fields indicated above.

Post Your Comment Close

Thank you for your comment.

Thank you for submitting your comment, your opinion is an important part of SandHill.com

Your comment has been submitted for review and will be posted to this article as soon as it is approved.

Back to Article

News You Can Use

Click here for news releases:

  • Is Data Science Dead? Watch the Carpe Datum Rx Debate - April 30
  • Join Ray Wang at SafeNet Lunch & Learn - May 8
  • Preparing for IPO: Streamlining Compliance in the Cloud - April 23

 

 

 

 

 

 

 

 

Topics Related to this Article