1 hour of research saves 10 hours of development time

I was recently talking to a developer who was building out a new stream view for a web app she was working on. She was in the middle of getting infinite scrolling to work, which isn’t very hard for developers these days but it does take a significant amount of time to do elegantly. My experience has shown me that in most cases streams are not the best way to present information. In fact, outside of social apps streams are rarely useful.

So I started asking questions about what the stream view was for. Who was going to use it and what would they do with it? Very basic questions. It turns out that the stream view was just another view the team thought might be useful, but they hadn’t actually talked to any users to confirm that. I asked why. After a few minutes of my badgering the developer looked at me and said “You know, I think we just are assuming it’s valuable”.

Now, it’s possible that the stream view is a good addition to this app. That’s not the point. The point is that a very small amount of research could have confirmed whether or not this was a good idea. As it was, the team was spending 20 or 30 hours building this screen….a significant amount of developer time! And for startups it’s an even more critical amount of time…because it is potentially taking away from some other growth activity.

Not only that, but there are other costs. The time to maintain the screen going forward is not trivial. And any associated support time as well. But the biggest cost is probably the most hidden, and that is the cost of additional overhead in the product for the people who use it.

Every feature adds complexity to your product. Even if you hide the new feature on its own tab it is taking up valuable space, not only in the UI but in your user’s heads. You’ve added another option that they now have to decide between. For the first feature added…not a huge effect. Over time, however, enormous. Every subsequent feature adds more and more friction.

It’s not scientific at all but I’m now thinking that:

1 hour of research ~= 10 hours of development time.

Or, in longer terms if more people appreciated how one day of user research can save weeks of coding I think they would do it more. It is remarkable what you decide to not build after talking to a few people closely. And it is remarkable how much you can learn from just asking a few questions or showing a mockup to a couple users. I have a background in usability and design, so I’m biased, but it’s basically just being curious and asking questions. Anybody can do it.

So if your hammer is the ability to code, don’t just hammer everything in sight. Ask a few questions first. Take an hour or two to make sure you’re building the right thing.