Share this post
Working with Erin Jo Richey changed the way I think about building software.
There's a kind of software development I like to call checklist development. That's where you just draw up a long list of features you want your software to have. This could be based on your own intuition, or it could be because you have a collection of stakeholders who have all told you that they want certain things.
The end result is a kind of shopping list of software features. You might take that list and have someone else develop it, or you might develop it yourself. Either way, it's the single worst way to build a software product.
Throw out the shopping list.
I already knew that checklist development was a harmful antipattern. You need to have the right features, built in the right way, to solve real needs.
What Erin has brought to Known is an intellectual rigor in finding those needs. It doesn't matter if you've been working in software development for thirty years. Building based on your assumptions is not the same as determining unmet needs through a scientific, data-driven process.
The first week Known existed as a company, we had countless phone calls and conversations with the kinds of people we thought we might want to build it for. We just shut up and let them talk, and Erin created a framework for distilling that information into actionable insights. (She also open sourced the scripts she used.)
From there, we created simple prototypes of product iterations that built on those insights, and tested them again. Those prototypes didn't need to be software, and in fact they were worse if they were; the lower the fidelity, the more people projected their own assumptions onto them, and the more we learned.
We've run design thinking workshops at universities to glean real insights from students, faculty and staff; we've spoken to a huge number of people about specific markets like podcasting and chatbots; we've covertly created lots of different kinds of prototypes in order to learn and iterate.
My instinct is often to intuit and try to be a kind of software artist; all the while, Erin has rigorously questioned our assumptions and found ways to test them. Of course, being a startup cofounder, she does a lot more, too. But I think this approach to design is unique in open source projects, and still fairly rare in software overall.
Design is a science.
In the two years we've worked together, I've often thought that "user experience design" is the wrong term. For the layperson, it implies visual design, and the craft of building a beautiful user interface (even if design is, in truth, a much larger and richer field). In fact, user experience design is about applying scientific user research to the product idea itself, and then continuing to use research to iterate that product in order to make sure it's meeting their needs in a satisfying way.
A lot of developers think of design as a superficial layer that you add at the end. Instead, if you're serious about making something that people can actually use, it should be the thing that comes first. And second. And third. Scientific design should be part of every stage of development. Development becomes one part actual engineering, one part investigative journalism, and one part data science.
My first question used to be: "what can we build?" Now it's: "who can we talk to?"
I came from the huddle-down-and-just-build-something school of development. It took me a little while to come around. But these days, I wouldn't do it any other way, and that's all down to Erin.
We approach projects differently.
This different approach means that, when we work with external clients, we like to make sure we understand the core needs first. A checklist of feature specifications can be a negative signal (unless you've already done your own empathy-based needs-finding). We like to hear about goals and real people.
The good news is that Erin can help you find those needs, and tease out those user stories, through the techniques she's developed. Then, she can create a low-fidelity paper prototype - usually wireframes - to get feedback. From there, higher-fidelity prototypes can be created and tested, bringing you closer to a final product that actually meets a need - and therefore is more likely to succeed.
That's how we do our projects at Known, both for ourselves and other people. We find it allows us to build better online communities. I'm never going back to building in a vacuum - and neither should you.
(What if you don't need Known? That's okay too. Legend has it, she also does her own freelance user experience consulting.)