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)

The text is accessible, timely and stands out from vapid books written by self-acclaimed social networking gurus, and steers clear of technology features or trends with a predictably limited shelf life. Instead, Dr. Howard uses a number of examples, many of which span diverse domains ranging from gaming to higher education, to elucidate how people will interact, socialize, and collaborate with each other when provided a fertile opportunity and motivation to do so.

Predictably, Dr. Howard’s guidelines for communities across domains, industries, and audiences are not meant to be a one-size-fits-all solution. For example, we see such a divergence when determining how people within enterprise communities find and share documents, answer questions, or otherwise collaborate online.

Specifically, when discussing remuneration, Dr. Howard recommends most community managers or administrators shouldn’t provide or curate an archive of knowledge “if they want to ensure the long-term health of their communities” (74). His argument, at first glance, is understandable: if community members or the general public can simply find and download materials they seek, there’s little need to contribute to the discussions and activity ongoing inside the community. Dr. Howard reiterates “public archives are only good for the people who want to get in, get their answers, and get out without giving anything back to the community” and ultimately risk silencing the community by “bottling it up in an archive” (75).

But in the workplace, enterprise or not, people don’t always have time or interest to ask a question and wait for a follow up response that may or may not adequately address the original question. An archive or repository of frequently accessed documents provides the community member more time to dedicate to his or her job, and focuses the activity within the community on more valuable collaboration.

For instance, providing an archive shifts activity in the community from simply asking where documents are to generating activity on the contents of the document itself. People can add comments or create discussions about the document rather than simply asking the community where the document can be found, whether it’s the latest version or not, or if it was warmly received by management.

In addition, an archive provides community members with validated, authoritative content. The knowledge seeker trusts the document’s official status (rather than an outdated draft) and can feel comfortable referring to the document in further work.

Conversely, some people may want to find different approaches of a similar document across different communities. While this is certainly what Dr. Howard refers to as not giving back to each community, the value of predictably, consistently finding information across communities is still a success for the knowledge seeker and the business.

Some social software providers recommend that after the same question has been asked over email or in a discussion thread that the topic be addressed in a blog post, wiki, or a sticky discussion thread for future access. Often these vendors also have tagging functionality to assist in future findability by community members.

In other instances, similar to those I see in my workplace, an archive is critical to even launch a community in the first place. At my current employer, many community members are published, well-known experts in their field, whether that field is pharmacology, animal health, chemistry or biology. Providing an archive allows these experts to share documents within their communities without constantly being hounded for the same documents over and over again, and frees up these experts’ time to cooperate on important topics. Such archives were a condition to even consider generating communities across the enterprise.

Dr. Howard rightly states archiving content stifles collaboration before it can start, in some cases. But in the enterprise, enabling self-assistance via archives and repositories leads to more productive, efficient communication within communities, and empowers the employee to find his or her own answers. Consequently, focusing the activity within enterprise communities should lead to greater adoption, activity, and employee engagement.

I was honored to be invited to the conference to conduct a spin-off of my UX Show and Tell workshops. The audience participation proved once again what I’ve been seeing across the country and into Toronto and London: that there really is a pent-up demand for user experience designers, interaction designers, information architects, and others to pull back the curtain from their work and share the goods or ask for help.

But as my session didn’t occur until Sunday, I had plenty of time to catch up with old friends from DC, my recent colleagues in Philadelphia and New York, and to finally meet a number of people with whom I had either communicated but never met or simply didn’t know until our time together.

Though I took away a lot of important insight in the sessions and keynotes, my real appreciation of the time lies in the moments spent forging new relationships or re-galvanizing existing ones.

My personal highlight of the conference occurred Saturday morning, when my friend Jeff Parks asked if I could sit in on a low-key discussion about design research with a few other folks. It wasn’t until a few moments before the UX Workshop’s video cameras went live did I realize I’d be having such a discussion sitting next to Indi Young, Eric Reiss, Daniel Szuc, Steve Baty, and of course Jeff himself.

Our conversation (which will be posted to www.theuxworkshop.tv thanks to sponsorship by New Hampshire-based Mad*Pow) spanned numerous topics involving design research, such as knowing what to investigate and how to dig deep enough, convincing clients when you need more research or perhaps even less, and much more.

Not only was the discussion itself valuable, it also granted me the opportunity to finally meet some of that Mad*Pow team, including Amy Cueva and Megan Grocki. I had been aware of their stellar work for some time but had never crossed paths with any of their team in person.

My workshop was a success despite a curveball at the last second: though we were planning on a discussion-style format, we couldn’t get the room converted from a presentation-model layout to round-table in time, and because lunch required the round-tables we’d have about 45 minutes for Show and Tell (usually the workshops are about 2 hours or more).

Will Evans quickly volunteered to kick off the Show and Tell by discussing some of the deliverables originally appearing in his “Right Way to Wireframe” workshop held on Thursday of that week. Will’s work process quickly captivated the audience and also showed the crowd that discussing your work doesn’t have to be all that painful.

Other presentations followed, ranging from people looking for help with their design approach, to other folks who wanted to walk through prototypes of their work to get feedback.

I’ll be the first to admit there were some unique challenges to the Show and Tell, but fortunately with a bit of adjustments I’m convinced such a workshop has an important role in an international conference attended by practitioners of varying levels of experience and expertise.

Looking ahead, I want to continue to build the UX Show and Tell brand with more of the connections I established in Savannah, and I’m sure the natural partnership with the IxDA will provide such a fertile foundation for growth.

Professionally, I can’t wait to engage with this crew in the immediate future and beyond, in any capacity, be it on project work, over a few drinks socially, or again on the conference circuit.

From a professional perspective, I’m beginning a long-term consulting position as a UX Strategist with a major pharmaceutical company to help design a socially-rich enterprise intranet application.

The personal perspective is equally beneficial: I’m really excited to move my baby girl closer to my wife’s parents (my Mom lives in Indiana and my Dad is in Hilton Head, South Carolina) . In addition to my in-laws are numerous cousins, aunts, uncles, and my wife’s two brothers who I’m closer to than some of my friends. If it takes a village to raise a child, then I’ll trust this village of family moreso than the alternative.

So between the great work environment, both for this current gig and whatever comes next, not one but three rich UX communities, and the opportunity for my own family to be closer to more family, the decision really wasn’t that tough.

I’m also looking forward to expanding my network of user experience professionals to include New York City, Philadelphia, and New Jersey, and rest assured I’ll continue rebel rousing the UX community to share their work at UX Show and Tell workshops throughout the region.

But that doesn’t mean UX Show and Tell is leaving the Washington DC area. My friend and fellow UX designer John Douglass will pick up the flag and facilitate workshops in the area. He’s already accepting reservations for our next event on January 12, 2010.

I’ll certainly be back in DC soon, but I also can’t wait to see more of you in Philadelphia and New York for UX Show and Tell, and I encourage you to join me for for lunch on Sunday at Interaction 10 in Savannah, Georgia.

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.

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.

Paul Sherman‘s recent article Usability Testing ≠ A Good User Experience attempts to establish that usability testing doesn’t guarantee good user experience.  Claiming that the only reliable method to developing a good user experience is “strategic design”, the author asserts that focusing on “tactical usability” is a myopic exercise.

I certainly agree that rigid, task-focused usability testing is unlikely to glean new insight into a product or service’s user experience.  And a usability test can often hinge on the quality of the script and system and the personalities of the moderator and participant. But does user testing only elucidate whether people can successfully complete a given task? I have my doubts.

Dr. Sherman’s argument that usability testing doesn’t quantify user enjoyment is not new. Long before User Centered Design principles were accepted in development teams, software interface designers and developers still needed to assess the usability of the systems they unleashed to their clients.

In an effort to de-humanize usability testing and provide quantitative results, engineers often relied on GOMS (Goal, Operators, Method, Selection) and Keystroke Level Models to assess the usability of existing systems.

Often these findings would be presented in numerical reports claiming that Feature A was 1.4% more usable than Feature B under strict, predictable circumstances.  Such tests proved effective enough for years of practical use, though today they almost seem quaint when compared to the user-driven research practices of the present.

Today, most software developers and their management teams need and want usability tests to reveal how people feel about their application, while also confirming their audience can successfully complete step 2 before attempting step 3.

Usability scripts can elicit how people feel about a system, and a moderator tasked with observing participants’ interactions and emotions can also glean valuable insight, at times even tabling task-based questions to prompt a particularly effusive participant to expand on how she feels about the system.  Granted, you can’t “tactically” assess those emotional reactions, but it’s also safe to say it’s difficult to fundamentally quantify any user experience as well.

Dr. Sherman continues that usability testing cannot “craft a unified user experience, plan for tomorrow’s user experience, [and] create delight, loyalty, and stickiness”.  Well, that’s certainly true.  But a usability test or other user research can identify if the user accepts and welcomes the unified experience from screen to screen and through the system’s interactions.

And a usability test can also provide insight into how to build future releases of software or web sites as well, or what may not be important at all.

Perhaps most importantly, I could argue it’s the usability test that will prove whether the designer is creating a system that is capable of instilling delight and loyalty.  I’d much rather stand behind a system that’s been put in front of my target audience and generated feedback than trust the words of my designer that he sprinkled some “strategic design” into his workflow.

Back in 2007,  UX Matters published Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent wherein Dr. Sherman wrote

Above all, our goal is to bring the users’ wants, needs, abilities, and limitations into the organization, and ensure that the organization doesn’t forget the user during any of the design and development stages

In my experience, usability testing is a prime opportunity to confirm your system is built with an understanding of those wants, needs, abilities and limitations.

The magazine is an open collective talking, sharing and finding answers about the interaction between people and products, systems or processes.

McCullough himself said that while new reviews have been limited (which is understandable for a 5 year old text),  few reviews have been “this helpful”.

Read the complete review and other insightful articles by such authors as Jeroen Van Geel, Will Evans, Adrian Chan and Steve Baty at Johnny Holland Magazine.

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.

In the context of  user interface design, even the term personality itself can be confusing.  Luke Wroblewski’s Design Philosophy summarizes that

The combination of a site’s organization, interaction, and visual presentation creates and supports the personality of a Web site…

and that

an appropriate and evocative personality not only tells the right story to your audience, but it also provides distinction, appeal, and wholeness to your site.

In short, tailoring navigation, layout, color, and messaging to your audience shapes not only how they’ll use your web site, but also how they’ll feel about the experience as well.

Audience Considerations

However, some people may argue that many web sites or applications are simply utilitarian: the user should be able accomplish his or her task without inconvenience.

Others may claim that spartan software with more functionality will be more appealing than software with fewer features but more personality.

But before we make sweeping generalizations that these people will always like that software and those people will always approve of this software, we must remind ourselves that the personality of web site must be tailored to its users.

Do EKG monitors need personality? Or do heads-up-display interfaces in jet aircraft cockpits require a fun interface? Of course not.  The priority shifts from providing the user that aforementioned “appeal and “wholeness” of the experience to relaying critical information free of distraction or clutter.

In other words, systems need to balance useful functionality with a well-planned strategic personality.  Unfortunately this is easier said than done.

Case Study

I recently purchased a Garmin Forerunner 305 to track my training as I prepare for four triathlons, a few ten mile races, and a half-marathon this year.  It’s a GPS-enabled personal training device that can monitor my heart rate, distance, time,  an estimate of calories burned, and a few other assorted data from each running or cycling workout.

While the device’s screen provides summaries of each workout, the device sends the GPS information and each workout’s data to my computer where I can view the relationships of each workout or a number of workouts over time.

Garmin provides its own software for analyzing my workouts, but the data can be imported by a number of other applications that aren’t developed by Garmin or its partners.

We’ll examine Garmin’s own Garmin Training Center, Berbie Software’s Trail Runner, and SportTracks by Five Zone Software, plus the less-robust Nike + system to determine if these user interfaces’ personalities enhance the user experience.

Welcome/Home Screens

The Garmin Training Center and Nike + display a home screen, whereas Trail Runner and SportTracks show the latest workout.

Garmin Training Center

Unfortunately, the Garmin Training Center default screen is devoid of any personality or utility. It simply reminds me I was born 31 years ago and my weight from when I entered it in January, and my name.   In addition, there are also numerous codes and zones, though they’re not tailored to my performance.

Nike +

The Nike + home screen takes a different approach.  Instead, the welcome screen displays the latest workout, complete with a Flash-based animated jogger showing bouts of extended speed and exertion.

Here we can see the stark differences in an application’s personality by comparing the Nike + screen and that of the Garmin Training Center.  It should be said that Nike’s intentions are likely different than those of Garmin’s, after all, as this web site is clearly a vehicle to drive their following to purchase new products.

It may also seem unfair to compare a Nike product, which no doubt has been combed over many times by their marketing and interactive agencies, to Garmin’s software that some may view almost as an afterthought to the device itself.

But simply seeing these screens together shows just how little attention or thought was given to the Garmin interface, even down to the decision to show the user’s birthday, weight, and name as primary information, leaving the workouts on the left as secondary.

Individual Workouts

Each of the GPS-enabled applications incorporate some map visualization into the interface, though some implementations are more crude than others.  For example, the Trail Runner system uses Google Maps, but the Garmin system appears to be a custom-built mapping engine, and looks like it belongs back in 1985.

Trail Runner:

The Trail Runner interface uses the Aqua interface components to deliver a consistent experience with the Mac user’s other applications.

This interface helps define the distinction between a good personality and a usable product.   It certainly looks the best, using the aforementioned Google Maps API, icons instead of burying everything in pulldown controls, and using color to connote similarities and differences between data.  Unfortunately, there are numerous usability problems at the task and process level, and not necessarily as a result of poor interface design.

That being said, an adaptable interface would be a huge blessing to the overall experience.  Though I will likely never go back to using the Nike + system, or use my iPhone instead of my Forerunner, these icons will stay cluttered at the top of the primary navigation as long as I use the software.  More advanced, or niche features, such as saving routes, managing my exercise plans and more may be better served for someone who uses the application for more than tracking runs, calories, and how frequently I exercise.

Perhaps crystallizing the argument that a good user experience can almost trump a less useful application, the personality of the Trail Runner application keeps me wanting to return to it, even though the system’s shortcomings continue to frustrate me.

Garmin Training Center

These screenshots from both Vista and Mac OS show that the bare, utilititarian application addresses the simplest use case: it displays how far I ran, where I went, and it shows my heart rate throughout the activity.

Vista top |  Mac OS below

Where is its personality? Good question.  The system buttons, controls, and components don’t tell any more of a story than a balance sheet. But the interface stays out of my way, unlike the more attractive Trail Runner.  In fact, if I didn’t know that this interface represented a person’s run, I’d probably assume it was graphing some complex engineering system.

Nike +

The Nike interface simply shows what data it has to work with: time and distance, and the speed over which that distance was traveled.

The bumps in the line indicate when the runner’s speed increases, and does not represent moving uphill or downhill as could be inferred by the running animation.

But even with the broken mental model of running uphill as an increase in speed, the interface still features more polish than the more advanced Garmin Training Center, and summarizes the information more prominently than the Trail Runner.

The soft shadows, gradients, and reflections all suggest a refined, sophisticated experience.  It’s also similar to many of Apple’s design assets, which strengthens the holistic bond between the shoe, pedometer, and iPod. And even though some of us in the design community may be tired of this look, it’s likely still perceived by their wider users as professional and accessible.

SportTracks

The SportTracks workout interface provides a unique approach compared to the earlier interfaces discussed here.

The personality is certainly down to business moreso than the Nike + system; the rows of data from prior workouts in the Daily Activity panel provide more context to the most recent workout (found in the Summary panel).  Some could argue that the interface doesn’t prioritize data effectively: quickly scanning the screen may not indicate where I should focus or what’s most important.   But perhaps that lack of heirarchy is part of the application’s personality: it’s designed to be put to work but flexible in how you use its features.

Workout Summary Screens

The summary screens don’t deviate from the personalities established by the screens discussed earlier.

The Garmin Training Center elects to display only numeric totals of distance and elapsed time in the top of table columns, whereas the Nike + system provides no numeric value of how far the user has run.

It’s unfortunate the Garmin Training Center doesn’t borrow from the SportTracks system and display a chart of my long runs compared to my tempo runs or cycling workouts; instead I get a crude map of Central America, central Africa and southern India.

The SportTracks (below)  summary interface maintains it’s rather bland personality while still keeping its data front and center.   I’m curious if additional data such as heart rate could have been represented using color in each bar representation of a workout.

Conclusion

These applications are proof that an interface’s personality can enhance the user experience. However, relying on such personality to compensate for usability shortcomings or limited features is difficult at best.

Determining what tasks users will want and use and the various mental models of how those users will engage with the system’s features are far more critical than applying gradients to backgrounds.  But when those backgrounds, in addition to layout, color, and language, cohesively align with how the user expects the web site or application to behave, a personality can develop that the satisfied user will turn to time and again.