The Dangers of Mobile App Development Without Design Documents

By John Houghton on April 9, 2015

In the last few months I have come across a lot of failed projects. I suppose the main reason for failure is because of a poor quality offshore team (or sometimes on-shore), but what contributes to failure and makes the project hard to salvage is that there are no design documents (a.k.a. Product Requirements Documents). A PRD can increase the quality of work of any team.

When the project comes to me and I’m asked to save it, I look at the barely functioning app and I’m not sure what it is supposed to do. Looking at the code isn’t helpful, because in looking at it, the previous developer didn’t seem clear about what was expected either. The code can also show several course changes and features that are commented out, and I’m not sure if my client asked for these or not. When I talk to the CEO of the startup, they are fuzzy on the specifics, partly because they changed their mind a few times and can’t remember the details themselves. Some of the problem too is they designed the app themselves and are “too close” to it to explain it. They assume that everyone can easily see what it’s supposed to do, when in reality, the UX (user experience) is primitive and nobody gets it. It’s frustrating for everybody involved and wastes a ton of time.

Design Documents Save Time

There is a cure for this and it’s called a design document or product requirements document. The PRD is typically written by a product manager, someone who is good at taking a step back and communicating with engineers (and customers/stakeholders) to get the desired results. This document lists the requirements of what the product is supposed to do at a high and mid-level of detail. It typically does not go into a low level of detail. If you have talented engineers, they typically figure this out and can work with your user experience resources to get the product built. The typical PRD might be 10 pages for a simple app and 40 for a complex app. Any longer and developers won’t read it – even the best. That’s why the detailed requirements document is rarely used. That level of detail would make for a long document.

There are many other documents that can come before or after, but the PRD is the Swiss army knife of design documents. I’ve interviewed a number of people on this blog and associated video program, Mobile App Development TV, who are from Google and Groupon and don’t use design documents. They just build prototypes and then move to production. I think this is great for them, especially if they are smart, talented, and experienced and they can do the whole thing by themselves and in their head. Most organizations can’t pull that off – not even close.

I remember when I was a teenager, I was watching an advanced student in a tennis lesson. His coach was trying to get him to keep his wrist straight, but the student answered that he sees the pros on TV flip their wrist all the time. His coach answered, “When you’re a pro on TV you can do what you want, but the rest of us have to keep our wrists straight!”

Communication Is Key

It’s the same with mobile app development methodology. Unless you really are a top development team, you should use the standard best practices. These are also important when you’re building out a team or if a key player leaves. There is nothing harder than a new team member coming into a tight knit team that has no time to communicate because it’s pushing for deadlines. However, if there are accurate and up-to-date design documents, the new team member can quickly understand what the team has done and where they are going.

“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw

Yes, it does happen that people are not on the same page and don’t share the same understanding about what needs to be done. This is typical at startups that are working so hard and growing so fast that they forget to communicate. Many more times the effort can be saved by taking the time to quickly document your design ideas with a PRD. A well written design document can get everybody on the same page and save everybody from wasted cycles due to miscommunication. Good documentation also makes your project easier to salvage if you have to let go of the original team and reassign it to a new team.

Posted in Android Apps, App Development, iOS Apps