When it comes to making software, sometimes the math doesn't add up. Take, for example, building a new feature for an app. It might seem that the first 90 percent of that work is more important than the last 10 percent, yet I'd argue that it's the opposite way around. The last stretch in the development of a product can make or break it.
The first 90 percent is obviously the most fun part of building something. You begin at a drawing board, sketching out ideas and features, and then move to Photoshopping, coding, alphas and betas. But it's at that point that you start to find all of the small problems you didn't anticipate back at that whiteboard.
While it might not seem like it from the amount of work you put in, much of the success of a product has to do with the decisions you make during the last 10 percent of development. Do you cut a feature if it's not working? Add a new design? Change the name? You won't know until you get to that last 10 percent. And making those decisions are sometimes a lot more difficult than you could anticipate.
Leave time to iterate in the development cycle.
Let's say you've built the most amazing app in the world. You open it up in your phone and start plodding around. "This is great," you think, "It will solve all sorts of problems, win awards, and shoot to the top of the charts!" But then, as you start to test it with your friends and employees, you discover that signing up for the app is really confusing. If you launch your app without taking the time to fix that small detail, it won't matter that the features are easy to use or that the app does everything you want it to do. Because people won't be able to sign up to use it.
The same will be true if you realize late in the development cycle that your app is really slow and takes a long time to load data from the network. Or if you find at the last minute that the "forgot your password" button is too hard to find. That may seem like a little detail, but it prevents people from using your app, and no one is going to experience the amazing features you spent all your time building.
The best designers are able to think about the last 10 percent and the details right at the beginning. They have a solid understanding of technical constraints and can anticipate what will be confusing to users. But no matter how good you are, there's no way to know everything that's going to happen until it's built. This is something first time designers and companies that hire outside design firms often don't consider.
If you are hiring an outside design firm, as many app developers do these days, make sure the contract is set up so that they're around to help you ship a great product, not just get a certain amount of work done. If that's not possible, you'd better have someone within the company capable of dealing with the design issues that will inevitably come up.
The execution is more important than the idea when it comes to product design.
There is a reason for a test cycle, and it's not just to find bugs and tune performance. It's also for making sure the product is adhering to the original design vision. When you only leave room to test for bugs, it's very possible to ship a stable product that doesn't solve the right problem or that nobody gets excited about. Have the discipline to cut an entire feature if it doesn't feel right. And if the feature is essential to the product, consider moving the deadline.
I will point to an issue we ran into with Storehouse's iPhone app, which launched in September. Here we were with the beta version of the app 99 percent ready to go, and in playing with it we all started to realize that having the audio from people's stories autoplay every time you open the app is incredibly annoying. We'd be in a meeting, and someone would open an iPhone, and loud sounds would fill the room. That wasn't something we thought about while staring at the whiteboard. Yet this was something we clearly had to fix--and we thought we were done.
I've coined a term for solving problems like that: "patchwork design." Essentially this refers to the cover up work added to a product after it's been built--not a core feature, but something that you build in order to let the core feature operate in the right way. A great product will have several of these added at the last minute, most of which you will never notice. Sometimes it's as simple as adding descriptive text and other times it's resizing buttons to make them more noticeable. You simply experience the product as "working."
Sometimes the beauty really is in what you don't see.