7 Ways Design Can Speed Up Your Product Development

One thing I hear a lot from startups that don't want to bother with design is, "But design will slow us down!" They're sure that the fastest way to get a good product in front of users is to just jump in and start coding and then iterate on the feature or product once it's been built and released. Guess what? They're wrong.

A good designer who is willing to work with a lean development team can remarkably speed up your progress. Let's look at some different ways that design can help you quickly get your product into the hands of your customers.

I Can Design Faster Than You Can Code

So, you think you're a pretty fast coder, right? I believe you. But, unless the feature is dead simple, you can't build a working version of it faster than I can build a fake version of it. Remember, my prototype doesn't have a backend or a database. It doesn't have privacy controls. It doesn't have to support multiple users. It doesn't even have to work at all. It just has to look like it works.

Getting rid of all those requirements makes my prototype really, really fast to build. That means I can build several versions of it in the time it might take you to get the backend set up. If I make those versions seem like they work, I can get the prototype in front of users, get their feedback on it, and iterate much faster than you can.

That means, by the time you build the real version, it's already been through two or three versions and validated with customers. Many of the major usability problems will already have been found and eliminated. Complicated things will have been simplified. You'll already know how it integrates with the rest of the user interface. If you assume that you'd need to do all of these things anyway, this will save you time.

I Don't Need to Design it All Upfront

Maybe you've only worked with waterfall-style designers in the past, but there are some of us who don't need two months and a full set of specifications to get a product designed. We can get started on the broad outlines just a little before you begin coding and have something ready for you to get started with right out of the gate.

Besides, all of the products I've ever worked on had at least some non-customer facing code that needed to be written, so maybe you could write that part first. If you have some idea what you're coding based on things like customer stories (you did write customer stories, didn't you?), you can get started on anything the user doesn't see, and I can get started on everything the user does see. By the time you're done making sure the feature isn't going to bring down the servers, I can have built and tested a few mockups.

It Takes Very Little Time to Not Build A Feature

Imagine that the product owner has a fabulous idea for a feature that will really wow a particular set of current users. Now imagine that you build that feature and get it in front of those users and they just shrug, totally unimpressed. I'll bet that's happened to some of you.

Now, imagine that, instead of taking the time to build the feature - even a minimum viable version of the feature – I was able to determine that the users wouldn't be the least bit interested based on interactive mockups. Granted, this doesn't work in every case, but it can sure save a lot of time when it does. It might even save enough time to let you build something that we figured out users DO want based on our interviews using the mockups.

I've Probably Designed One of Those Before

I don't know how to design a multi-threaded event system that can scale to millions of users. That's ok, because it's not my job to design those. My job is to know how many steps I should break a particular registration flow into and to have some idea of how that will affect user behavior. My job is to know when and how to use progressive disclosure of information to keep a screen from becoming too cluttered and distracting. My job is to know how to subtly encourage a user to follow a call to action.

Now, maybe you know how to do all of those things too, but most engineers I've worked with don't. I know how to do all of those things because I've spent a lot of time designing things, reading about designing things, talking about designing things, and watching people use things that I or other people have designed.

Just because you can put a button on a screen doesn't mean you know how to get people to click on it. This means that you may need a lot more iterations to get to the right solution than I do. This means that things tend to go faster if I'm the one deciding design things and you're the one deciding engineering things. Don't worry. I won't tell you how to write your multi-threaded event system.

I Know How to Change Things Without Hurting the UX

There are a lot of ways of doing most things in an interface. Some of them take a lot longer to code than others. Now, maybe you're one of those few engineers who love to do things the hard way, but most of the ones I've worked with have deadlines and want to get things done as fast as possible. This may mean not wanting to do the things that take a long time.

When you're deciding how to build things, I can help you understand how your decisions are going to affect the user experience and suggest other ways to get the same effect, some of which may be faster to build.

Tossing a Prototype Has No Side Effects

Let's say we do let you just start coding without testing any mockups. Let's say that a whole lot of what you built wasn't right. That means you may have to throw out large chunks of your code.

Now let's say that we test my mockups and that I was the one who wasn't right. That means that I have to throw out large chunks of my prototype. But you know what? I was going to throw away the entire prototype anyway, so it's not that big of a deal. I mean, I don't love being wrong, but that's part of the process. Sometimes we don't get it right the first time.

Throwing away a stand-alone prototype is a lot less hassle than ripping code out of production. It never generates any surprising bugs in other parts of the code. It doesn't leave any bad data in the database. It has absolutely no impact at all, because it's just a prototype and was always meant to be thrown away. That's not always true of production code, especially when you're dealing with adding a feature to an existing product.

I Can Keep You from Throwing Away Something Almost Great

You spent all that time building something and now users hate it, so you have to throw it away, right? Maybe not. Even the best feature can be so confusing or poorly designed that users don't know how desperately they want it.

Having a decent, validated design up front means that you're less likely to throw out a feature that has potential. At least if users hate the feature, you'll know that they actually hate the idea and not just that they didn't understand how to use it or what it was supposed to do.

How Do You Get Started?

Now, to be clear, not all designers are going to improve your velocity. You need to integrate the designer into your development team and make sure that he or she is comfortable working at these sorts of speeds and in a startup environment. You can read my post on Embedded Design for more tips on how that works or send me email at laura at usersknow dot com with specific questions that I will try to answer.

Make sure you get somebody who can quickly make interactive prototypes and who has enough of a background in user centered design to get feedback on those designs. Also, get your designer involved very, very early. As soon as your product owner is writing user stories, the designer can start thinking and sketching, so the design can get a bit of a head start on development.

If you do it right, your end product will not only be significantly better, but it will also take less time to develop. And yes, at times it may seem like it will postpone coding for a brief period at the beginning of the development cycle, but it will actually speed up learning, which is something I think we can all agree is a good thing.

Like the post? You should follow me on Twitter!