From Design Vision to Reality in 5 Steps
In user experience design, there’s no shortage of perspectives on the creative process. But generally, we all know the drill:
- Clarify the business problem.
- Capture and prioritize user needs and behaviors.
- Establish your design objectives.
- Collaborate with stakeholders to identify and refine possible solutions.
That’s not to suggest this process is easy. In fact, it’s downright hard to reconcile all of these disparate inputs into a single, elegant, and strategically sound product vision.
But anyone who’s been designing products long enough has seen plenty of early, inspirational design concepts lose steam or fall apart as they move from concept to reality. Many factors contribute to this degradation, hardly unique to any project–constraints on time, budget, resources, and other business realities. But even with constraints the story need not end badly.
The solution depends on designers taking an active, influential role in the work to decide how the project team will realize the concept. This article outlines five steps to help you and your project team proceed systematically toward realization of the design concept.
Identifying the right design concept or vision that conveys where a product needs to go and what it needs to do in the long-term, anchors and informs the rest of the process. Arriving at the right concept or vision for a product is the subject of another blog post, but you need to recognize a comprehensive concept design when you see one.
In short, good design concepts paint a high-level picture of what the product should be, what it will do, and how it will impact the lives of its users. I’ve seen this information communicated in many ways during my career including: slides, concept models, wireframes, and most often interactive prototypes. While format and delivery methods vary, high-level concepts will always tell a story about what the product should be and do, hopefully across the lifecycle of the product. The most powerful concepts position the product in the lives of its users.
Conceptual designs are often (intentionally) void of detail. Their purpose is to align the project team around the strategic direction of the product but not get too bogged down in constraints early on in the process. But even lacking the design detail, good product design concepts allude to the things that need to exist or happen in order to realize them. Deconstructing a high level concept into its component parts is as important as understanding the big idea.
Your deconstruction into design requirements must go beyond the user interface. They should include everything that’s necessary to deliver on the concept–such as “make energy consumption data available to the interface in both BTU and KWH units…”, or “allow users to create and distribute graphs directly in the interface, using..available data”, and so on. During this process designers must document what content, functionality, data, and business processes are necessary to deliver on the design concept. This task falls at least in part to the designer, and should not be left to requirements analysts alone.
This is the most important task you’ll perform before you get into detailed design specification. Without it, the team won’t have something describing what to build. At the end of this activity, you’ll have moved from a conceptual idea to a more tangible set of requirements necessary to build it.
3. Prioritize & Plan
Once you have a base set of design requirements, you need to assess and prioritize each of one against the objectives determined at the beginning of the project. You classify each requirements as either essential or non-essential. Consider a three-tiered priority list as follows:
- Essential, Foundational: The concept cannot exist without these elements. Without these, the integrity of the concept is lost entirely.
- Important, non-essential: Important elements whose presents increases effectiveness of the concept. Without these, the concept remains stable but not as effective.
- Nice-to-have: Nice touches whose absence does not significantly impact the effectiveness of the concept.
This is easier said than done. It forces designers to analyze what’s truly important and what falls into “nice to have”. That often means letting go of some of your favorite ideas and focusing on the foundational elements that move the team toward the product vision.
For example, on a recent project, our primary objective was to make data more accessible to expert users of a web site. We included an idea for a custom graph generator that would enable users to plot key data points visually. Though the idea appealed to all project participants, it wasn’t the most important design element for us to pursue, at least initially. We had more fundamental problems to solve. And although we proposed it, we needed to recognize its place and priority as part of the larger vision. In the end, the graph generator wasn’t essential to the objective. And by not including it, we were able to focus on delivering on the essential elements sooner and at a higher-level of quality than we would have otherwise.
Knowing what’s essential and what’s not, allows the team to more effectively plan and phase how the project will proceed and what scope will be tackled when. It helps to establish a logical, more systematic and measured way of delivering on a concept.
4. Design & Build
After you’ve prioritized requirements and collectively defined a release plan, you can begin to execute on it. You’ll prepare design specifications explicitly aligned to the scope for each phase or release increment. And although you’re focused on a designing against a bound set of requirements, you can prepare your specifications with an eye to the future. For example, you might explicitly identify where functionality is abbreviated or left out because it’s destined for a later point in the timeline. Explicit hooks into the future help the project team plan how to build the product to anticipate these upgrades.
During this process, there will undoubtedly be instances when something you originally conceived doesn’t work out (at least as you planned) and/or introduces new, unanticipated requirements. This is to be expected. When this happens, be prepared to identify scope impacts and negotiate when and how to incorporate this new scope into the bigger plan and project phases.
Admittedly this is a big and demanding process. But, it’s important to realize that the work you perform here will be much more controlled and manageable if your specifications are comprehensive but differentiate what to build now and what to save for later.
5. Assess and Recalibrate
As the product comes to life either in test or in production through incremental build phases, your focus shifts from the trees back to the forest contemplating big questions such as:
- How well does what’s been implemented map to your original priorities and plan?
- What changes or trade-offs were made either for the better or for the worse?
- What have you learned during the process that may alter the direction you need to go with the next planned phase or release?
- How will new requirements be addressed and integrated into the project plan?
The point is to step back and assess what you’ve delivered as a team and determine if you need to recalibrate or change direction for future phases. It’s inevitable for new learning’s to emerge and pressure the direction and plan that you set out to execute. As such, it’s important that the team recalibrate after each planned phase or release and confirm gaps and directional shifts to the scope and plan.
Design success doesn’t end with creating an elegant solution to a problem. It includes being able to deconstruct that solution, figuring out the best way to approach the implementation, and executing on that plan. This rigorous definition, planning, and specification process is one we as the designers need to embrace and drive if we want that original concept to see the light of day.
Originally published at www.eightshapes.com.