Dennis Eusebio asks:
Many design thinkers really advocate deep, rich design research. Its a lot of documentation, interviewing, meetings and even more documentation just to get to the planning/prototyping stage. After reading some of the literature 37signals has put out, it seems like you guys stray away from this workflow in general. What’s your general workflow like? Is it different from traditional design workflow?
We conduct research all the time. But it’s a different kind.
It’s important to know that research is guesswork. The further out you try to guess, the bigger your margin of error. Like you said, many people do research before they start building their product. They write lots of documents and diagrams and specifications. The problem is, it’s all hypothetical. Until you’ve actually thrown the ball at the wall, you don’t know how it’ll bounce back.
People often think that research is like preparing for a long journey. Like the more food you stow on the ship the safer you are. But you don’t want to go on a long journey. You want to take as short a journey as possible, and come back for a reality check. See how you’re doing, then go for another short trip. Long journeys are the death of software.
I said we do a different kind of research. Here’s how we do it. We build something, then we collect feedback on what we built. For unreleased products, that feedback is our own opinions and review process. Does it do what we wanted? Does it feel right? Is it easy to understand? Will it support more features and future changes down the road? In the case of released products, we always listen to emails and forum posts from our customers. In both cases, the feedback on what we’ve built arms us for the next phase.
It’s like a conversation. You don’t sit down at the cafe, listen to your friend for two hours straight, and then talk for two hours straight. You take turns, constantly going back and forth, and the discussion finds its way.
Of course, you might wonder how to start. We build products we need ourselves, so our initial research is made of our own wishes, itches, and frustrations. When it comes to client work, my best advise is to become friends. Spend time together and discuss what they do until you can see through their eyes a bit. Pay special attention to their language and the words they use. Make notes, but don’t put them in the documentation shrine. As soon as you know enough to build the first basic feature, do it. Break away for a week or two and build it. Then come back, talk about it, learn more, and decide what to build next.
Research can make you feel informed, but I guarantee that building real software in many small steps gives you a lot more knowledge and confidence. If you’re interested in how to better share headspace with your clients, I highly recommend absorbing the Ubiquitous Language pattern from Domain Driven Design.
