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)

Joel Spolsky of Fog Creek Software recently claimed on his blog that “when people are successful at controlling their environment they become happier, and when they can’t control their environment, they get grumpy”.  This can certainly be true. But does this mean we, as experience designers, have to concede control to the user to provide a favorable experience?

Let’s take a look away from the glow of the laptops and monitors and go outside for an appropriate, though perhaps seemlingly reaching, example.  As an avid golfer, I’ve played a number of courses where the layout of the course is prohibitive to walking.  As a result, I’m required to use a golf cart, many of which are equipped with global positioning system software.

The GPS system often features scrolling sports scores, the club house’s menu with one-touch ordering, the ability to summon the on-course beverage cart, and of course the layout of the particular hole we’re playing, complete with multiple views of the fairway, green, and so on (the blog post discussing these GPS golf interfaces is for another day).

While these features are a great amenity to the experience, it also allows the pro shop to monitor exactly where I am on the course and to confirm I’m keeping up with the pace of play.  The software also regulates where I can drive on the course, either to protect its property (by forbidding the cart to drive onto greens or into bunkers) or to protect me (by limiting the speed of the cart, particularly on steep slopes).

In short, though I feel like I can drive the cart anywhere and as fast as I want, the software system is actually well in control of the environment but offers me an implied perception of control.

Such a paradigm of perceived control works well in the software space as well.

When designing software, the ideal experience does not provide total control by the user, but a perception of control by offering relevant, context-aware tasks and content to the user.

For instance, many online shopping cart and registration process flows remove the site-wide navigation to limit distraction and to focus the user’s attention on the imperative task.

From the business’s perspective, regulating what users can and cannot do can protect users from themselves and prioritize important actions or content.

See the screenshot from the familiar Amazon.com checkout experience as an example of limited navigation.  The user cannot begin browsing for another book here and risk abandoning the cart. Likewise, the user cannot undo any information that’s previously been submitted which could confuse and aggravate the user.

In other cases, an adaptive interface may be instrumental in providing users a feeling of control.  After all, if a fledgling investor just opened an account with $1,000 in a money market fund and identified himself as a novice investor (required during brokerage registration), there may not be a strong need to offer foreign currency exchange research as a primary option.  Of course, such links to currency exchanges are available, but not as prominent as more common tasks based on the persona model of a novice investor.

And while much of Spolsky’s article really cites the benefits of system feedback and not user control, there are a few strong examples that outline how we can design software that provides this perceived control.

For example, Spolsky discusses how implementing AJAX allows his software’s users to manipulate table columns and employ keyboard shortcuts.  Indeed, the ability to drag or hide table columns or send keyboard commands to the system can certainly instill a feeling of control in a user.  If these features were designed to be available after the user was familiar with the system then that sense of control should be heightened, as the user will have developed his confidence in his skills and mastery of the system.  Immediately providing these features risk burdening the user with distracting glitz.

So while it’s certainly true users may say that want full control of their software, the systems that offer a perception of control while monitoring how its users interact with it will have a sturdier foundation with which design a better experience.

Over 45 minutes, we discussed an introduction to human factors, cognitive psychology, and interface design heuristics. And since Mr. Brown’s class is in the beginning stages of a web design project for a local business, we also used the time to focus on identifying audiences, task modeling and other discovery-themed processes.

Mr. Brown has done an exemplary job at recruiting phenomenal speakers to talk with his students–to the point that many of his speakers contact him requesting to speak (I fall into this camp).

His students certainly appear to enjoy a dialogue with practitioners who have real-world experience that they can immediately apply to their own schoolwork, and hopefully put to use for years to come.

Hopefully more high schools, community colleges, and universities will begin or continue to interact with the technology community to benefit their students.

But us practitioners cannot wait to be contacted.

Instead, we should introduce ourselves to those who could benefit from our experiences.  Yes, it’s personally rewarding. But more importantly, those experiences can shape the thought and actions of our future interns, colleagues, and partners.

But what happens when you find yourself on a project or worse, a full-time job restricting how you can provide an ideal user experience for your business’s users and clients?

While every job, gig, project, or contract is unique, there are some shared opportunities that lie in even the most muddled of projects.

Below are a few methods to provide the best user experience possible that could go undetected by unaware bosses, managers, and others.  All of these cases assume the UX practitioner has pleaded for user testing to sort out these issues but such requests have been denied or ignored.

Problem:
Client has already determined the information architecture, navigation, and labels of the site and won’t listen to dissenting opinion.

Solution:
Even if your client demands links in the primary navigation to include  “Misc.”, “Hit Us Up”,  and three red circles to indicate three unique categories only revealed on mouse-over, you can still find some opportunity to make such dreadful navigation more useful than if you quickly nodded your head in surrender and began debating whether to jump off the building head-first or tucked in a cannonball.

If the client has decided what the navigation will be,  hopefully you can determine how it will be built:

1. Rely on semantic code to at least provide some meaning by using an unordered list to arrange the links rather than a table with columns and spacer gifs.
2. If the client requires images in the navigation (assuming you’ve provided the boilerplate warnings against doing so), use the images as background images of the list-item tag so you still have legitimate markup in the tag itself, and use CSS to only show the background image.
3. Use alt and title attributes as appropriate. If the boss really wants “Hit Us Up”, you may be able to get away with “Contact Us” as the link title.
4. Make the entire list-item clickable, not just the text itself.  Increase the size of the hit-state for easier clickability.
5. In addition to color, use font weights or other styles to distinguish links from one another.  Color is unreliable to connote meaning as it’s susceptible to cultural interpretation, it varies across displays, and some users could be colorblind.  If you’re using text links, consider displaying primary links in bold, and secondary links in normal font weight.

Problem:
The boss hand-picks terribly cliched stock photography for the home page, and even cornier text to overlay on the image.

Solution:
It’s safe to say laughable stock photography and feature text will burn you right in your craw every time you look at the site whether it’s the first time or 500th time. But regardless, here are a few ideas that could be worth explaining in an interview when the creative director asks how you’ve handled adversity.

1. If the featured text isn’t grammatically correct, take a chance and lay it out with corrected language.  Granted, you may get your hand smacked for changing exactly what was submitted, but you could also be the last line of defense before later embarassment that will look like you failed to catch.
2. Attempt to add additional creative changes to the photo so it looks less like everything else.  As long as you don’t follow other cliches or trends, such as ink blotches, swirls, stickers, or slanted lines, altering the hue, color, or sharpness of the image may breathe some originality into the image.
3. Holistically lay out the image with the rest of the site.  Even if the image is unoriginal and the text is terrible, it will stand out even more if it’s wider than its host column or shorter than a complimentary shape or image.
4. Even if the text’s meaning is awful, you still risk looking like an amateur if you don’t lay it out well.   Yes, even “Think outside the box” can look acceptable with the right font in the right place.

Problem:
A task or process is complicated, unconventional, and confusing, and you cannot alter the sequence of steps due to technical limitation.

Solution:
Hearing that step 5 always has to come before step 3 because a programmer from 6 years ago built it that way is always frustrating, particularly when competitor sites execute similar tasks flawlessly.   But a few helpful tips can make confusing steps a bit more predictable.

1. Provide an overview of the steps necessary to complete the task at hand.  Inform your user what lies ahead so you limit surprises.
2. Continue showing those steps during completion, including steps yet to come, and steps that have been successfully completed.
3. If technology allows, provide the user the ability to revisit earlier steps to confirm his or her input.
4. Pick the low hanging fruit.
   Provide inline form validation, usable calendar date pickers, and let the system format data as necessary, instead of the user.
5. Provide helpful definitions…
   Use pop-up tips or definitions immediately following the unclear concept, not off in another column across the page that may go unnoticed.
6. But don’t overwhelm the user with “helpful advice”
   If you inundate the user with the aforementioned tips (i.e. the label First Name includes a tip reading “Enter Your First Name”), you’ll dilute the quality of the tips that are necessary to leading the user to success.  Using only a few tips will let the tips you need stand out.

We don’t always have the luxury of working with perfect clients or sublime art directors. But there are opportunities to enhance the user experience even when crippled by draconian design guidelines.