Design currency
I just discovered a podcast and Medium post in which Jonathan Courtney, Jake Knapp and Jason Fried —discussed a “controversial” 2017 tweet from Fried:
The podcast dove into much more and is worth a listen, but the initial topic was a discussion on the value of user testing.
One of Fried’s responses was to balance the cost of testing with the cost of not shipping. This reminded me of a core concept that I use a lot at our company but rarely explain: What is your design currency?
In other words, how do you measure the costs that Fried described?
My hypothesis is that Fried’s design currency is a shippable iteration of his company, Basecamp. (Note the distinction; this is not the same as a shippable feature for his Basecamp product.)
User testing slows down Fried’s ability to “mint” more currency, and so testing is devalued. Human feedback after shipping increases the value of his currency, because it reveals ideas for adding or revising new features to his company. Basecamp’s transparency (e.g. its public-facing employee handbook) is another manifestation of this approach: Ship for real, get feedback, rinse, repeat.
At our company, our design currency is the hypothesis (which is itself a hypothesis). Obviously, our context and needs as a design team are much different than Basecamp’s. Our goal is to help customers improve their pace of innovation with new approaches to solving difficult problems, many of which rely on custom solutions and improving human behaviors. We don’t ship “one solution fits most” products as a rule.
So, how do you get to the best solutions? For our team, the hypothesis is the most effective unit of currency.
Initial and proven hypotheses (the latter via experiments and user testing) are important to us because the insights we derive from them are often more valuable to our customers than the solutions we ship. Furthermore, the cost to change a solution is almost always more after shipping than before. In that sense, our design cost structure is very different than Basecamp’s: User testing greatly increases the value of our currency.
Could our “proven” hypotheses still be wrong once introduced in the wild? Possibly … but in our experience, we’ve proven more successful when we use tested hypotheses, and less when we don’t.
That said, our unit of design currency doesn’t work for all projects. In fact, we have one solution that’s mainly tested after production, because the cost of pre-ship testing is too high. The design currency for that project? A testable feature.
At the end of the day, context matters and the best process is whatever gets you to the best possible design outcome. That said, you might be able to make better decisions as a designer if you can figure out your unit of design currency, and design your process around maximizing its value.
