Chiara Fox Ogan of Adaptive Path writes “there is a lack of clarity around what tasks and events go into making an implementation successful” in her recent post “Strategy & Design; But Wait, There’s More”. To bring light to the processes and milestones in a typical design effort, Chiara provides a high-level process flow identifying significant milestones and where the primary strategy & design tasks drop off and implementation work begins.
After reading her post and the accompanying diagram, I wanted to add my own thoughts as to how design strategy could act not only as a bridge to implementation, but also a foundation supporting it as well. Essentially, I’ve front-loaded Chiara’s diagram with more tasks to understand why and what to build, and some activities post-launch to measure results of the redesign effort over time. I’ve found such steps increase alignment and clarity among design and implementation teams and ultimately increases the likelihood of a successful product or service.
Revised Redesign and Implementation Roadmap [PDF 100kb]
(remarks in blue are by me and completely independent of Adaptive Path)
Summary:
- baseline metrics of current state
- identify key business needs
- define success criteria & primary design objectives
- conduct a competitive analysis before a feature/value analysis
- keep the product or service’s roadmap & vision at top of mind
- compare post-launch metrics to baseline statistics
- consider unexpected use or feedback to inform roadmap
First, I should briefly add I have no inside knowledge of the scope of the Adaptive Path document; I’m not saying it’s missing anything. Rather, I’m simply adding onto the diagram based on my experience with successful multi-release or multi-redesign projects.
My additions to the AP flow call out the business problems the redesign should address, what should be built to answer those problems, how to adhere to that plan through implementation, and how to know if the design is successful after launch.
Even at a high level, we can see how referencing primary design objectives and prioritized business needs can add focus to a problem space apt to be derailed by the usual suspects (feature creep, reprioritization of resources, etc).
Baseline the Current State
As we delve into closer inspection of my additions to the document, we can also understand what informs those primary design objectives and the key business needs. For instance, prior to the strategy and design phase where AP begins the discovery effort, I emphasize the importance of baselining the current state prior to the redesign. These numbers will provide the foundation to know where we are today so we can ultimately measure how far we’ve come after launch, and with subsequent releases.
Roadmap & Vision
This early stage is also an opportunity to engage other stakeholders to provide their input into the key business needs that will support the entire project. While fleshing out the business needs, now is also useful to begin formulating the product or service’s roadmap of where it should be years or versions down the road. If the redesign is already adhering to an earlier roadmap or vision, confirm the business needs under discussion are still in alignment with the vision, which ideally should be the case. It’s also useful to compare the baseline metrics in the context of the roadmap to determine what to improve or what has worked well since release. I should also reiterate I certainly believe AP helps its clients understand business value, draft product roadmaps, and analyzes numerous data before recommending solutions to its clients, but in this case I’m simply adding it to the process flow here.
Primary Design Objectives
Moving left to right, I attach my Competitive Analysis block to the AP Discovery block as it’s possible the competitive or market analysis is assumed to fall here. Regardless, the discovery phase, including a comprehensive competitive analysis, should lead to a identifying the primary design objectives (a more tactical summary of what the new design should accomplish based on the key business needs).
The primary design objectives then inform the feature/value analysis, which pegs each piece of significant functionality to a key business need and design objective (and often assigns a priority/demand rank and another representing technical effort or complexity). For instance, if a key business need is to reduce employee distraction at work, creating a new Foursquare-like badge system across the Intranet probably isn’t useful. However, if a key business need is to foster employee camaraderie and to encourage participation in Intranet tasks, then a badge system may in fact drive business value.
Feature/Value Analysis
The feature/value analysis helps the business, design team, and developers agree what will be built before diving into wireframes, prototypes, or even screen description diagrams. It also can prioritize what needs to be dropped off or de-scoped if necessary, or what else to develop if the team finds unexpected bandwidth.
With the baseline metrics in hand and an overall understanding of what will be built based on the feature/value analysis, the team can identify specific success criteria as the project moves primarily into the tactical design phase. Success criteria help train the team to understand the big picture of how to reach success with specific targets, milestones, or concepts. Keeping the goals specific maintains that strategic focus from one step to the next, and defining how success will be measured keeps everyone aligned, stakeholders included, into what everyone is marching toward.
During Implementation
As the Adaptive Path flow accurately depicts, there is still plenty of opportunity to self-check the implementation effort isn’t drifting from the overall design strategy. For example, as rounds of usability testing conclude, the design strategy is a useful guide to confirming you’re not making knee-jerk reactions to test-participant suggestions, as helpful as they may first appear. Of course, I’m not suggesting such a design strategy is rigid and static, but it’s also easy to allow usability test results open a Pandora’s box of unscoped, unprioritized work.
Post-Launch Review
The only other significant addition to Chiara’s diagram is at the conclusion of the process. Rather than end the flow at launch and editorial clean up, I added a few important tasks that again, I’m sure AP practices on every project but are important to see in the context of the entire redesign/implementation undertaking. Specifically, I recommend comparing the redesign’s metrics and KPIs to the original baseline statistics. While it’s important to fully understand the integrity of the numbers and the nuances that could be in play (such as was there a media campaign or new product launched that would also drive more traffic to the site or service), these figures can usually indicate whether your efforts have been successful, particularly by measuring regularly over time.
It’s also important to note any outlying, unexpected, or unusual statistics that could indicate whether or not you should consider adjustments to future releases in your roadmap. If the way the product or service is unexpectedly being used supports the overall design strategy and business objectives, there may be value in paving those cowpaths.
Remember, for the most part, creating and maintaining the design strategy is a participatory effort—it’s not, nor should it be, the work of a few thinkers without an awareness of the step by step tactical efforts to proceed through a plan. Even in situations when the strategy & design team completes its pre-implementation work and moves on, a concise, focused strategy supports future development efforts by providing reference points and primary objectives to measure against. As a result, the design strategy keeps the project out of, as Chiara describes, the “murky wilderness, with unknown snares and dangers the client is left to navigate on their own”.
Revised Redesign and Implementation Roadmap [PDF 100kb]
(remarks in blue are by me and completely independent of Adaptive Path)
