Published on | Prototyping: From UX to Front End — Medium Patrick V. Barrett

I have a deep respect for journalists and believe reading the news gives us a more complete picture of the world we live in. At the same time, as is driven home every time I read an article on a subject I’m passionate about, or even have a passing familiarity with, journalists get many facts flat out wrong. It’s understandable, they’re under tight deadlines, with limited resources, speaking to only a handful of fallible sources. We should have no higher expectation of any article we read than it being directionally correct. Those directionally correct articles still get us a better understanding of the world we inhabit than coming from complete ignorance (for a less charitable opinion on the value of directionally correct journalism see Michael Crichton’s quote about the Gell-Mann Amnesia).

As product teams, we face very similar challenges trying to collect research on our users as journalists do when writing a story. We’re under tight deadlines. We have limited budgets to conduct research. The users we have access to may not represent an accurate sample of our actual user base. The users we do interview are also fallible. The very act of observing a user when they know they are being observed taints the objectivity of your research. Users being observed in a lab simply won’t behave as they do “in the wild.” Even if you miraculously were able to overcome all of the above, your users are not fossils frozen in time at the moment you observe them. They are constantly changing, and a valid insight you have about them today may become invalid as they change and grow as people (example, remember the old adage that users don’t scroll, and you cannot put anything beneath the fold).

Those are the challenges on the user side. On the product team side, there are plenty of challenges as well. Have you ever sat through a qualitative interview with a user only to have you and your co-workers draw completely different conclusions? We’re just as fallible as the users we’re observing. We have opinions on what’s right and what a user should be doing (for example I have a bias toward what I consider attractive design, and will naturally overweight answers that favor attractive design and discount answers that favor unattractive design). We have our egos tied up in our work. We mishear things. We fill in the user’s gaps and pauses in ways that are unique to us. One could argue an impartial research team could clear up many of these biases. But most organizations “can’t afford” an independent research team, and researchers have the same human flaws as you, plus a journalist’s challenge of learning enough relevant facts about your product to have proper context.

Learning to love plausible models

User research will not get us the truth, but is will allow us to construct something very valuable, a plausible model to build from. It’s directionally correct. A plausible model doesn’t necessarily represent the truth about your users, but it does represent a cohesive view of your problem, given all the data you have at the moment. The same inputs can give you many different plausible models, and that’s fine. If they truly are plausible then one is not necessarily better than another.

As a product team looking to build great product, it’s important to execute with certainty. You need to believe in the product you’re building, or no one else will. The tentatively built product, a product built with indecision, will show in the final product. You’ve seen it:

A product that offers you seven different ways to complete the same task.
A product with excessive amounts of UI helper text because you’re just not sure your user will get it.
A product with too many settings and configuration options because you’re uncertain how a user really wants to interact (hint: no user wants to spend their time messing with configuration options in your product. They want to spend their time accomplishing their goals, and very few users have “spending time messing around with your configuration options” as their goal)

With a decent plausible model in place of who your users are, their constraints, and their goals you will be able to build a product with conviction.

And that’s what user research can provide us, a plausible model that’s good enough to build the best product that we can, at the moment. After your product is launched continue to do research, and refine your model, or discover completely new ones. Execute with certainty when you’re building your product, but revise with humility knowing that the research you built on has not provided you the one and only truth, but just a pretty decent plausible model that’s allowed you to move forward.

Building Better Product with Flawed Models was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building Better Product with Flawed Models

Cool stuff, every week

More Articles