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.

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.

Some people think so and are rethinking how web design should be taught at the university level.

The problems, at first glance, are as obvious as they are abundant: technology changes too fast, university administration doesn’t offer worthwhile courses, draconian hiring guidelines mean interested industry experts without advanced degrees can’t teach, among others.

On the other hand, we risk over-correcting these perceived problems if our academic institutions simply play catch-up to technology.

Leslie Jensen-Inman‘s Elevate Web Design at the University Level, published last month in A List Apart, is a call to action to the web community and universities to change how web design is taught at most universities.

The Assistant Professor at the University of Tennessee at Chattanooga interviewed 32 web design and development leaders searching for insight and opinion into how an undergraduate education prepares students for working in web design.

Jensen-Inman mentioned that generally, the 32 industry leaders indicated “these educators don’t have the resources to do what needs to be done”, and James Archer, CEO of marketing agency Forty, went so far as to say that his shop “won’t hire anyone who comes out of a university web design/development program” because “the culture of large educational institutions has, in my experience, consistently proven itself unable to cope with the demands of such a varied and fast-moving industry“.

Archer’s opinions open the door to finding many of the answers.  However, those opinions also lead us to questions regarding the diversity of Jensen-Inman’s research.

First, when Jensen-Inman acknowledged the people interviewed were web design leaders, she may have been a bit modest.  Many of these people she cites are published authors, mainstays on the speaking circuit, and are generally household names among practitioners in the industry.

Why could this be a problem?

Because it seems unlikely many of these first-class agencies would hire entry-level talent directly out of college anyway.  While some of the quoted personalities work in larger teams (Cameron Moll leads a team of 30 practitioners of diverse backgrounds, for example), the majority of those interviewed appear to work either independently or in small boutique rock-star agencies.

I would rather have seen the interviews include leadership from companies who have hired young talent in the past, or at least make those who do stand out.  Here in Washington DC, nclud and Viget Labs quickly come to mind as studios that have recruited recent grads who may not have a shelf of Webby Awards (yet) or a client list that reads like the Fortune 50.

I’m also surprised at the choice to exclude academic representation in the ALA article–particularly given Jensen-Inman’s assumed accessibility to college faculty, including her current employer, and where she studied her craft (University of Baltimore, Savannah College of Art and Design).  Here we could have read unique perspectives from a private art school and a public institution, with both undergraduate and undergraduate programs.  Jensen-Inman’s graduate-school colleagues could have also provided another glance at what they thought of web design in their experiences as well.

That said, there are a number of ways we can improve the skills of future web designers (not computer science majors, information systems majors, etc.) without sacrificing the academic integrity of a four-year liberal arts education.

My recommendations include:

1. Offer certificates, not degrees in web design
2. Allow industry experts to teach
3. Create knowledge sharing opportunities for consistency among faculty
4. Integrate web design concepts in more classes

First and foremost, four year colleges and universities shouldn’t be offering 60-credit majors in web design.  With the cost of college today, students willingly asking (or wishing for their parents) to pay at least $3,000 (for an in-state 3 credit course) for 16 weeks of basic HTML instruction or how to use Flash is ridiculous.  Similarly, 16 weeks of generic “web design” isn’t thorough enough to teach someone the difference between an h1 tag (vocational) and a mental model (abstract, academic).  On top of that, a student may graduate with a degree in something more complex, well-rounded, and potentially meaningful than how to position a background image.

Enter the certificate.  Graduate certificates are increasingly popular as a means of securing post-undergraduate accredited recognition of completing four to five courses in an area of specialization, without the time and expense of a complete graduate education.

Likewise, if students had the core knowledge of HTML and CSS (bear with me, I’ll get to that in a second), they could enroll in a small number of academic but professionally-focused classes at the undegraduate level (similar to this and this and here, not something like this).

For instance, I created a mock curriculum for a 15 credit undergraduate certificate as follows:

1. principles of interface design
2. choose one of two (depending on background):
   typography & design theory
   advanced presentation layer coding (PHP, JavaScript, advanced CSS, etc.)
3. choose one of three:
   human factors & human-computer interaction
   information architecture
   introduction to web-based databases
4. 2 semester-long internships in different agencies, departments, etc.
5. one special session determined by industry expert (pass/fail non-credit class)

Students interested in such a certificate will likely already be coming from a design or development background, or at minimum, have an interest in going down a design or development path.   If a studio art student already has completed extensive courses in typography, then she would enroll in presentation layer coding to learn more about how to implement her ideas on the web, and vice versa for students coming from computer science or information systems classes.

Many of these courses are also already taught today across many college campuses, though perhaps by different names or exist only for graduate students.

Furthermore, and perhaps most important, is we keep an undergraduate education from turning into a vocational education and chasing technology.  Quite the opposite, in fact: principles of interface design haven’t changed that much in 20 years, and such a class likely woudn’t be deconstructing last week’s gallery submission in trying to recreate gradient effects.

The education stays conceptual and philosophical and offers skills applicable in the workforce.

Some readers may quickly point out that such a class requires basic knowledge of HTML and understanding how an HTML page links to another in a browser.

(edited 2/13/2009)

As mentioned earlier, web design is far too complex to fit into one 16 week course, but is also comprised of many important elements that don’t necessarily require a full semester of time to explore and master.

Let’s see more 100 and 200-level classes that lay a foundation for how to design a web site using industry standards and best practices, and introduce timely, but not necessarily technical topics, such as accessibility, universality, semantic code, and how to use CSS and responsible implementation of multimedia and graphics. At this point, an interested student would likely be prepared to continue her academic career by studying graphic design, marketing, or information systems, or something completely unrelated should she so choose.

But we shouldn’t stop at those introductory classes.  Returning to Jensen-Inman’s  ideas, I would advocate enlisting the web community (or skilled graduate assistants) to teach vocational, non-academic “how-to” 8 week special sessions in web design fundamentals, likely about 2 hours per class, two classes per week, that could run throughout the calendar year so students are exposed to best-practices and informed instruction before they’ve established bad habits and even worse fundamentals.

These classes would be open to anyone with the cash–regardless of major, year in school, or lack of web experience. (end editing)

These instructors would also provide special break-out sessions to further explore their areas of expertise, be it in design patterns, kinetic typography, AJAX, or something else entirely.  Ideally, if the web community develops a dialogue with those in higher education, there could be more than one special session available at one time, providing students the choice of pursuing a more tailored learning experience.

If these instructors have a graduate degree, that’s great. But we can’t continue to turn away motivated, qualified, experts in the field who understand the technology and have a passion to share their knowledge.

I’m not giving a free pass though: if you want to teach cognitive psychology, go to graduate school.   But I don’t believe someone needs an MS to instruct students how to design for multiple browsers.

Jensen-Inman’s article also expands on a significant factor in improving web design in higher education: knowledge sharing between practitioners and faculty alike, through conferences, the blogosphere, and elsewhere.

When I was teaching, the entire direction of the class was completely up to me and independent of what was taught either in the past or simultaneously by other instructors. As a result, I was left to develop my own lesson plan, in-class lessons, and assignments without a community or network to offer guidance or advice when needed.

These classes would then feature consistent curriculum even if the instructor changes from session to session, and allow the instructor enough leeway to provide personal emphasis in his or her specialty.

Furthermore, let’s expand how the web and multimedia can go beyond portfolio sites in art classes. The more students engage in problem solving where the solutions are in web-based deliverables, the more those students can begin tying abstract concepts to concrete answers. Students learn that not every problem needs a nail, and not every answer starts with a hammer.

When I was an undergraduate, one of my 400-level (senior) English classes substituted a final term paper for a multimedia presentation analyzing Emily Dickinson’s poems.  Another senior-level class opened its doors to students from the art, computer science, and English departments to create critical presentations in Toolbook investigating themes in the silent films of Communist Russia.

Were those forward-thinking, abstract courses recently discovered at an elite art school in New York or San Francisco? Hardly. I went to the University of Maryland. In 1998.

Do I reference “Bronenosets Potyomkin” on Tuesday staff meetings? Bring everyone down with a Dickinson reading after a successful launch? Of course not, but such skills, acquired early in my career, certainly help when a business analyst has a problem and wants me to design a solution.

I’m afraid if our colleges and universities begin offering majors with classes in how to create printer-friendly style sheets and connecting Visio shapes to one another, those students who think they’re getting a leg up on their web design competition may realize, as Matt Damon’s character says in “Good Will Hunting”, they “wasted $150,000 on an education [they] coulda got for a buck fifty in late charges at the public library”.

relevant background:
I earned an English degree from the University of Marlyand in 1998 and taught web design at the Corcoran College of Art and Design from 2005 to 2006.  I also completed graduate study in human factors and human-computer interaction from UMBC in 2007.

Clarification (updated 2/13/2009):
Based on a few emails and other correspondence, and re-reading my position, I’d like to make clear that I’m not advocating that all things web, technology, or computer be removed from four-year colleges and Universities and college students go back to studying Sophocles and Aristotle under an olive tree.

I wholeheartedly support a college curriculum that includes advanced topics pertaining to web design: information architecture, human factors, graphic design, interface design, how to use JavaScript, and more.

What I don’t support is a 3 credit class in how to use Flash, or 16 weeks dedicated to JQuery.

A 3-credit introduction to web technologies, open to all students (not just computer science or engineering majors), with a curriculum that includes the myriad ways of learning outside the classroom, is also benefit to the student and the web community as a whole.

As a result, a student can graduate with a degree in art, architecture, or mechanical engineering and have a strong background in modern web design without having to choose between one major and the other.

“Doing user experience”, or designing wireframes, prototypes and a sitemap (sans user research) will leave some people thinking they’ve completed what they see as the UX family of deliverables.  Some assume with a heuristic analysis in hand, they can finally check off UX from their punch list and move on.

Whitney Hess‘s recent article 10 Most Common Misconceptions About User Experience Design addresses how UI design is often thought to be interchangeable with user experience design.  Her summary rightly states that the interface design is but one piece of a puzzle that has many different corners, edges, and pieces.

If experience design was in fact user interface design, then it would be perfectly logical to assume that if a company’s web presence featured a bad user interface, or poorly designed interaction patterns, then likewise the user experience would also be poor.  Likewise, any company with a good user interface would therefore have a good user experience. Right?

Wrong.

Since a user or customer experience is a holistic engagement between a person and the company offering a product or service, and not simply tied exclusively to the interface that acts as a medium or messenger, we cannot assume that if one element fails that the entire experience is a failure.

Forrester’s 2008 Customer Experience rankings reveal enlightening affirmations that a good or bad web site interface is no guarantee of a happy customer.

Southwest Airlines, the list’s highest rated airline,  has surprisingly basic user interface troubles in trying to pay for a flight, yet their customers overlook such design flaws either by repetition or because they and their bags arrive where and when they want to for a fair, clear price.   In such a case, the ultimate goal of the site, and the company, trumps a faulty design pattern.

Conversely, Comcast’s cable and internet customer experience ratings are at the bottom of the list, despite a fleet of knowledgeable, competent user experience staff and industry experts who have worked with a number of their divisions.   But even though Comcast’s various web presences are easy to use and generally a success, a good web site is useless if your cable modem isn’t working and the Comcast repair technician is catching a few winks on your couch.

None of us who try to define and design a user experience should simply assume that if the user interface is good enough that business will come and customers will be happy.   But the UX practitioner who fails to review all customer touchpoints–mailings, newsletters, call center activity, event the front desk–and solely focuses on what color gradients to apply on the web site does so at his or her own folly.

So what are anti-patterns?  Simply put, anti-patterns are “some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results”, and summarized as “commonly re-invented bad solutions to problems” (Wikipedia, Anti-pattern).

Documenting these anti-patterns was recently discussed on UXmatters by Peter Hornsby, a Senior Information Architect at Friends Provident in the United Kingdom.  While I take issue with Hornsby’s examples he uses (Shiny Thing Antipattern?) the ability to name an anti-pattern is an early step to identifying it elsewhere.

Anti-patterns shouldn’t be mistaken for poor usability.  After all, some anti-patterns are perfectly usable, as people have been exposed to the anti-pattern for so long (i.e. some wizards) they are trained in how to use it effectively.  In other cases, the anti-pattern, while usable, is just an adequate answer, not the optimal solution.

Likewise, avoiding anti-patterns does not guarantee good usability either. Every day people find new opportunities to screw up a good design pattern.

So is there a definitive list of  anti-patterns? The aforementioned Bill Scott published a PDF of a presentation he gave for eBig in 2008 covering these anti-patterns:

• meandering way
• borg idiom
• tiny targets
• hover and cover
• pogo stick navigation
• novel notions
• metaphor mismatch
• double duty
• linkitus
• windows aplenty
• animation gone wild
• misguided misdirections
• missed moments
• one at a time
• non-symmetrical actions

While many of the above anti-patterns cannot be understood by label alone, any reader who downloads the presentation should have an understanding of a “novel notion” or a “linkitus” anti-pattern.  That said, let’s take one of Scott’s anti-patterns and apply Hornsby’s formatting (with a few minor changes) to a live example found a year later in 2009.

Antipattern name:
Novel Notion (Scott, pp. 59-68)

Background:
A Novel Notion is creating a new interface for a common idiom that is more confusing than the original.  Sometimes mis-using a component for a new unintended purpose.

Most frequently sighted:
Often used in forms or custom controls that can be easily replaced with off-the-shelf functionality.

Root causes:
Desire to be different or to use every available component somewhere in an application.

Anecdotal evidence:
“Check out this new way to scroll” or “It looks like a radio button, but it’s actually a trigger…”

Consequences:
The bait and switch: users presume they understand how something will work, only to realize it’s different from what they expected

Known exceptions:
There could be times when a new control, or a collection of controls, is the only available means of executing a process.   If your users will be interacting with the new control repeatedly over time, their repetition should result in familiarity with the control.

How to Avoid:

Understand the purpose of each type of component. For example:

• Carousels do not replace scrolled lists
• Drag and drop is not for single attribute setting

Don’t construct an artificial interface to support an idiom (don’t create the house for the nail)
A novel approach will work if it is intuitive (but what is intuitive?) Scott 68

Example:

Here’s a news box coded in standard HTML markup that relies on JavaScript to scroll content instead of using a familiar browser scrolling control.

What the designer makes up for in keeping with their intended appearance (regardless of whether or not it looks good), they lose several cues available to the user had they used standard scrolling.

Specifically, if the designers used conventional scrolling controls, I could look at the size of the scroll bar itself and determine how much news content is actually available based on what’s currently displayed.

Furthermore, I could also understand my relative location of what I see versus what’s available.  I’m disoriented–am I reading the most recent news story, or the last? Or am I somewhere in the middle?

In addition, moving the mouse over this custom scrolling widget begins moving the content–another departure from standard, conventional scrolling.  Since most people would expect a click-action to begin movement, the sliding content likely surprises the reader as it disappears off the page.

Lastly, I cannot click in between the scroll arrows to jump down from one group of stories to another.  I’m forced to use these arrows that have no over, idle, or inactive state to read the content I want.  Simply using a normal scroll bar would have alleviated all of these issues and would likely have only required a simple CSS modification, rather than complicated JavaScript.

Spool then is interested to see if his readers have any better ideas that could make the screen communicate more information easily and concisely.  As someone who regularly (maybe obsessively) tracks packages, I was eager to spend a few minutes using simple design patterns and prioritizing user-centric  information and seeing how a new layout could benefit UPS customers.

My attempt:

Though this particular screen shot is for a package already in route (I already have a few things on their way so I just used live info), it should be easy to see how a package that has been requested to be picked up but has yet to be shipped could be communicated.

I also attempt to emphasize the delivery date, which, curiously, is often unfindable on a tracking screen.

And while I’m fascinated to learn my new t-shirt has made a pitstop in Kansas, I’m usually more interested in when it will arrive at my door.

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.

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.