Why We Love Being Completely Wrong

This is Part 4 of a Design Story from Mollie Callahan and Michelle Pomorski. You can start with Part 1 here.

Why We Love Being Completely Wrong

Failure can give designers crucial insights about their users — as Mollie’s and Michelle’s stories show.

Jeff:  

Any stories come to mind about failures that you really learned from?

Mollie:

What’s interesting about that question is, I think we can only really fail if we can’t figure out how to build a relationship with our client of trust and open-mindedness to move forward. Because, really, our goal with our design processes is to fail faster. Right?

Michelle:         

It’s all about failure.

Mollie:  

We want to find out what doesn’t work, validate where we’re inaccurate, test our assumptions and catch ourselves being wrong and assuming incorrectly, and we want to tease all that out as soon as possible, learn from it, iterate, and move forward. So I think that’s a success in itself.

Jeff:

Can you give an example of that?

Michelle:  

In every single design assessment.

Mollie:   

Every project.

Michelle:

Every single project has these major “aha” moments. It’s really common to see the HTAs [High Tech Anthropologists®] come back after a design assessment, and people will say, “How did it go?”

And everyone will say, “Great. The entire reporting feature completely bombed.” But what we’re celebrating is that we didn’t actually build it and launch it into the world. And then instead we know why it wouldn’t work and what we might put in its place.

Jeff:  

Is there an good example that comes to mind?

Michelle:

One example is from an engine maintenance technology project. We knew we had to have a login feature, but when we were doing observations, we didn’t see anybody ever logging in to these tools. Our hunch based on other projects was that one person would log in, and everyone else would just do their work under that login. So we created three different designs to test this hypothesis: one didn’t require login at all, one required a username and password — your typical login — and the third was a numerical key code.

But all three designs assumed logging into the tool at the very beginning. What we learned really quickly, though, was that in practice, login doesn’t actually happen that way, which is why we didn’t see it. Login is instead reserved for more robust features, like completely reprogramming the engine — things you wouldn’t want a junior mechanic to accidentally do and in the process screw up the vehicle. And so only that type of feature requires a login. We were making an assumption that was completely wrong.

Jeff:  

And that assumption only came out in the prototype and in testing, even though before that you had been observing and gathering information during the discovery process.

Michelle:   

Correct. So we crafted our prototypes in a way to validate those assumptions and found out that all three were wrong. But then we knew why and we knew exactly how to approach it moving forward.

Next: Small Change, Big Difference