Don’t Skimp on Research, Design, and Planning

Our clients come to us with really cool ideas for web, mobile, and embedded apps. Usually, they know their domain inside and out, and they’ve come up with a great way to improve the world with some custom new software.

But we’ve learned over the years is that a little bit of planning before jumping into the code goes a long way.

We begin projects with an initial phase that we call Research, Design, and Planning (RDP). This phase is crucial to building the right software efficiently, helping you to get to market with a successful product as quickly as possible.

Why RDP?

But the truth is that there are a lot of ways to bring a piece of software to life, and not all of them are good. By collaborating with us during RDP, together we can identify the right product to build and the right path to take during implementation.

Here’s what an RDP phase can accomplish.

1. Educate Your Team of Makers

At the very least, RDP will help your implementation team (the AO makers who will build your software) become familiar with your business goals, users, and work flows. A team that understands you and how your software will help you, will be empowered to work in your best interest.

Your team of makers make decisions every day. Every feature they implement must be designed, architected, coded, and tested. We interact with you as much as possible when making these decisions, but we are much more efficient when we have a clear understanding of your goals and desires and can make good decisions based on a complete knowledge of the project when direct communication is not practical. Aligning the team around a common purpose is critical to a successful project.

2. Flesh out Your Idea

Some of our customers know exactly what they want to build and how it will make or save them money. Some of our customers have only an idea: “I want to make an app that will get me to the moon”, or “We need an app that will help us manage our factory more efficiently”.

But most of our customers are somewhere in between these extremes.

We start each RDP by getting a good understanding of what the problem is we’re solving with software and how the software fits with the clients’ business goals. We learn about who will use the software, and how and when. We learn about the process that is being aided or automated and map out a basic feature set.

This also helps the client. Even if you already know exactly what you want your software to do and who will be using it, the simple act of explaining it to us will help you to see your project from a fresh perspective and gain more insight into it.

Some of the artifacts that we generate in this stage of RDP are:

• Business ecosystem diagram
• Personas
• Design principles
• A high-level feature set

3. Apply the Big Picture to the Details

Once we understand the basic goals of the software, we begin to design for individual use cases, features, and views. We address how the software is organized, how users interact with it, and how information is presented. We consider alternative ways of doing things to find the approach that makes the most sense from the user’s perspective while respecting the time and budget allowed to complete the project.

We also help you to make hard choices about what makes it in the software and what can safely be left out for the first release.

Detailed design artifacts usually include:

• Work flows
• Mock ups
• Wireframes
• Style tiles
• Visual design guide

4. Create an Implementation Plan

While deciding what to build, we also plan for how to build it. Part of RDP is taking into consideration the software’s feature set, as well as security, privacy, and certification requirements, and from those:

1. Decide on the technologies that will be used (e.g. Ember vs. Angular, Ruby on Rails vs. Java, native mobile app vs. responsive web app, Sql vs NoSql database).
2. Plan a high level system architecture.
3. Consider hosting choices.

We also begin to estimate the effort required to implement each of the features (i.e. build up an estimated feature backlog), and produce a product story map to guide the implementation schedule.

How long should an RDP last?

RDP can last anywhere from 1 – 6 weeks. It all depends on how well-defined your product is at the outset, how polished your RDP artifacts must be, and how quickly you move from RDP into implementation.

If your product is very simple, or you come to us bearing design principles, personas, wireframes, visual style guide, and technology stack in hand, RDP will be relatively short. We can focus on transferring your learning to our team, setting up a development environment, and estimating feature implementation effort.

If we start the engagement with only an idea and perhaps a few rough sketches, RDP will require more time. Each of our RDP exercises, from business ecosystem diagram through estimated featured backlog, build upon one another to culminate in a plan that your team of AO makers can immediately act upon to implement your project. Each activity brings unique value to the project, thus they are all important.

When the basic outline of a new project is reasonably defined but there are few design artifacts at the outset, we recommend a 3-4 week RDP phase followed immediately by implementation. In these cases when we recommend a budget to you, it includes both RDP and implementation.

In some cases, however, if we feel that we don’t have a clear enough picture of what the software will be, we recommend an initial RDP engagement that may be anywhere from 2-6 weeks, and at the culmination we will recommend a budget for implementation. We feel that it is more responsible for you the client to spend money up front in better understand your customers and how your software will serve them before you start building.