I faced a number of challenges when writing the presentation. With only 40 minutes (including questions and answer time) I struggled with balancing how much to address business strategy, defining design strategy, and how to make the presentation practical and applicable to the audience.

Choosing to keep the presentation about how practitioners could begin creating design strategy using skills and methods already in their UX toolkit, I didn’t include many examples of how I’ve successfully used design strategy to understand and articulate what will be built before addressing how it should be built.

After hearing a few of the questions asked by the audience, I’d probably reconsider a similar approach if and when I present the topic to a different audience. It seems some of the audience thought it was challenging to connect the ideas to real business situations without a case study, which, in hindsight, is understandable.

It’s also clear that though I’ve facilitated more than a dozen UX Show and Tell workshops and have spoken to audiences of up to 50 people, I still need to continue practicing my delivery and stage presence.

Based on conversations before and after the event, over lunch at the Information Architecture Institute’s IDEA conference a few weeks earlier, and elsewhere, design strategy and its influence on business strategy is an important topic the UX community must continue exploring.

If I can ask or answer some of those questions during that exploration and share the results, be them positive or negative, I’m happy to help.

Big thanks to the programming committee and everyone involved who made the UserFocus conference such a success. It was great to see friends Dan Willis, Kim Bieler, Michelle Marut, Jimmy Chandler, Rob Fay and Ellie O’Connor in the crowd–thanks for your support, gang. Special thanks to Lynne Polischuik and Chris Palle for offering to help, and to Lis Hubert and David Panarelli for reviewing my presentation and offering fantastic feedback.

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

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)

UX Show and Tell is an informal workshop that’s all about the work, where designers can share feedback and ideas on strategies, outcomes, and deliverables, and meet other practitioners in a focused but relaxed environment.

Show and Tell participants brought a number of unique deliverables, such as concept maps and task models of complex web sites,  a process chart detailing how, where and when to integrate UX in an Agile software development lifecycle, and interface design mockups of a scheduling application.

I started the workshop sharing a deck of documents I used to provide visual conclusions from a number of user interviews and observations I conducted for the Library of Congress.  As user research continues to grow in recognition and importance, I thought there could be some value to *showing* how users behave rather than simply describing behavior in a Word or Powerpoint report.

…participants should be able to share specific solutions if they’re aware of the problems in advance…

I was hoping that the group would bear with me since it was the first workshop.  And not surprisingly, there were bumps in the road, from logistical issues such as starting on time to ordering food, to procedural hiccups such as how and when questions should be asked so as not to derail or sidetrack a presentation.

Fortunately, I’ve already begun incorporating participant feedback into future Show and Tell workshops.

For instance,  I’ll ask participants to identify what they’d like to share or problems they need to address during the RSVP process so other participants may be able to help. While I don’t want to see the workshop be so targeted that one session will only be dedicated to wireframes or another exclusively committed to persona documentation, participants should be able to share specific solutions if they’re aware of the problems in advance.

By identifying an issue first, the group can provide more direct, concise feedback.

Moving forward, the workshop will also run more smoothly if each participant quickly says what they’re sharing and what issue they’re having or where they’re looking for feedback.  During the first session, a few conversations began to wander off course when feedback that was meant to be helpful wasn’t entirely appropriate to the project or the project’s audience. By identifying an issue first, the group can provide more direct, concise feedback.

I also see the benefit to posting what was presented on a wall or whiteboard so the group can take a closer look at the documents. The photograph above shows how a number of deliverables were spread out on a conference table which certainly worked, but won’t scale well or support electronic presentations without a projector.

If your organization would like to host a UX Show and Tell, it’s really easy.

At the suggestion of one of the participants, I created a Google spreadsheet to list who attended with contact information to help expand each other’s network of practitioners in the area, many of whom had never met before.

I’m already discussing new locations to host workshops, both in the immediate DC area and beyond. If your organization would like to host a UX Show and Tell, it’s really easy.  Just have space for about 8 to 10 people, a table and chairs, and now a whiteboard, and we’ll set up a date.

Recently much has been written in academic and practitioner circles regarding how user-centered design should play a fundamental role in the development of software, web sites, and web applications.

However, UCD principles have yet to reach many development methodologies of today, such as agile programming, leaving the user experience of many task-based web sites under-acknowledged.

This paper provides a case study examining how user-centered design methods identify, design, and deliver the optimal user experience from the start to finish of a goal in an agile development
environment, and why these practices are imperative as we see a paradigm shift from
static information-based web sites to engaging task-based web systems.

Download the full document.