Project Blueprints

The final leg of Definition is a phase we call Project Blueprints. It is in this phase that we turn our focus in two extreme directions.

To begin with, we will look at our project through a telescope so that we may see and map the entire ecosystem we are about to design from a macro level. We do this by imagining our users taking a journey through the system and creating small stories about what happens to them along the way.

When we have told enough of those small stories so that when added up they satisfy all of the requirements we defined in our Project Pillars, it’s time to create a map of our system. It’s through system mapping and modeling that we can reveal how the system should be structured and organized so that our users may get through their journey with as little friction as possible.

Once we have our system mapped and modeled, we can turn our sights to the microscope. It’s here, that we dissect our user stories into the constituent parts required to actualize those stories. These requirements can define specific pieces of functionality, collections of content, or the rules that govern the visual design and branding look and feel. In any case, these requirements will comprise a bounded and quantifiable project backlog that we will design against as we move into our iterative Design & Development sprint cycles.

One of the most common pitfalls we see projects fall into is that they jump right into this project phase without having done the rigorous work of properly defining their Project Scope or Core Strategy. In that case, this can be a tortuous, chaotic part of the process that will inevitably cause the project to balloon beyond any design team’s ability to contain it. This is how projects find themselves in a never-ending development hell.

If, on the other hand, you’ve done the hard work set out in the previous phases of Definition, Project Blueprints can (and should) be as easy as falling in love.