Today we start a series of blog posts that dive into the design and development process we use here at AndPlus.
Our philosophy at AndPlus follows the Agile development methodology. By way of review, Agile breaks down a development project into short (one- or two-week) mini development cycles called sprints. A fundamental principle of Agile is that at the end of each development sprint, the team should have a working (albeit not necessarily complete) version of the software product.
Before you can start building a product, however, you need a design. You wouldn’t build a house without blueprints, and you wouldn’t put on an event (such as a wedding) without a plan. So, too, developers shouldn’t write any code without a design to code against.
The Product Map Sprint
As the name implies, the product map sprint is a short process in which we define the software product design.
Unlike more traditional development methodologies, in which the design phase could take weeks, if not months, incorporating a product map sprint into the Agile development process ensures that a comprehensive design is completed in a short time. Moreover, the output is a prototype suitable for review with the customer, who can then provide immediate feedback.
The product map sprint includes the following activities.
- Understanding the problem: The team researches the business problem to ensure it is fully understood. This includes understanding the different types of end users and what they need from a software solution, the business processes that must be supported, the constraints under which the system must operate, and interactions with other systems. The goal is to establish the boundaries of the problem so that the team doesn’t try to “boil the ocean.”
- Solution brainstorming: The team gets together to crank out ideas for possible approaches to the problem. No idea is too crazy at this point, but all ideas should observe the boundaries previously established.
- Solution selection: The team evaluates all the ideas, mixing and matching to come up with one “best” approach.
- User journey mapping: In this exercise, the path through the software, or user journey, for each user type is defined, with the goal of enabling all user types to complete their tasks and get what they need from the system. Through this process, the user interface design takes shape.
- Prototyping: Once the user interface requirements are established, a prototype of the system can be built. Numerous tools are available for this purpose, from sophisticated wireframing tools that can generate a highly realistic, semi-functional interface, down to paper, pencils, scissors, and tape.
- Evaluation: The customer, preferably including actual end users, is brought in to look at the prototype, simulate task execution, and provide feedback.
Why It Matters
It’s a fair question to ask: If we’re in such a hurry to get a working product out the door, why take a week or more for the design? Why not just give the developers a rough idea of what’s needed and let them get started?
Simply put: Too many software projects fail because they don’t meet customer expectations. Often this results from simply taking the high-level problem description provided by the customer and running with it. These descriptions are rarely, if ever, sufficient to flesh out a comprehensive design, let alone start coding.
The product map sprint is worth the time it takes because it ensures every detail of the business problem is understood. We end up asking the customer a whole lot of questions along the way; this is especially important if we’re not really familiar with their industry.
But most important is the prototype evaluation at the end. This is the customer’s opportunity to let us know if we understood their needs accurately and have designed a solution that will meet those needs. If we missed the mark, it’s better (read: cheaper) to find out at the prototype stage than at final product delivery.
Doing software design this way gives us peace of mind that we’re on the right track. We know, going into the development sprints, that the design will work and meets the customer’s needs because they’ve already reviewed it and given it the thumbs-up.
The end result is a better product and a happier customer. And that, ultimately, is the most important goal of all.
