Last week, I got a research alert from Forrester in my inbox:
For Customer Experience Professionals
How Rich Interfaces Fix Task Flow Problems
By Ron Rogowski
Multiple minor problems can add up to major user experience headaches on Web sites. But one of the most common Web design problems - inefficient task flow - can be rectified by enhancements such as page overlays that put content and function in context, . . .
For those unfamiliar, Forrester is geared toward marketing-related and C-level professionals, providing, among other topics, web design articles that could best be compared to Readers Digest versions of tips and hints. In the past year or two, they've gotten on a "Customer Experience" bandwagon, which may or may not be a good thing. They've rolled out a heuristic evaluation and made it available for their customers - never a bad thing - that for my tastes, is centered too much on the brand consistency angle than true user experience, but this is not surprising when we consider that their content is geared more toward the sales and marketing side of the house than product development.
I have serious issues with their pushing Customer Experience as equal to User Experience because it's not, and I fear that this will have ramifications for our field. But, this topic is for another post, or series of posts. My issue today is with the pronouncement that "Rich Interfaces Fix Task Flow Problems."
I know, it makes no sense. Aren't I pro-RIA? I am, but that's not the problem with this article. I'm pro-RIA, but more importantly, I am pro-User Centered Design (UCD), and this is what is completely missing here. I read the article and there were some good bits in there - things that I would like my favorite marketing director/C-level colleague to know, like the benefits of inline validation (a very good thing, if you ask me).
Generally, though, this article is off the mark. Here is what the article says:
"Firms can improve user task flow with rich interface features like:
- Overlays that offer content and function in context.
- Guided interfaces that progressively disclose key details.
- Inline input validation."
On the surface, this all looks ok. However, without careful thinking from skilled UX designers, this runs the risk of not delivering what is expected. While they talk some about what not to do - e.g. don't make users hover to find login information like they are forced to do on a Washington Mutual site, and don't make mouseovers close too quickly, nowhere does it mention the construction of solid design plans and approaches to ensure interface usability and consistency across all web content.
This article would be a lot more valuable if it went about this discussion differently and said something to the effect of "you can employ rich interface conventions to fix task flow problems, and here is how:
- study the problems your users are really having
- analyze those problems for similarities and differences across users
- create patterns or consistent approaches to solve these problems across all interfaces, including the use of overlays, guided interfaces, and inline input validation. If this is beyond your skill set or doesn't interest you, hire a skilled professional who can all make it come together for you."
But, you see, they have only stated the end of the story without mentioning the work that needs to go into achieving this successfully. They sort of get around to this with this footnote statement:
"To avoid delivering site experiences that fall victim to the cumulative effects of many minor problems, site managers should evaluate the most important user paths, focus on fixing problems with well-known solutions first, and put a business-centric design process in place to avoid building flawed sites in the first place. "
Let me highlight where I have problems with this statement:
"To avoid delivering site experiences that fall victim to the cumulative effects of many minor problems, site managers should evaluate the most important user paths, focus on fixing problems with well-known solutions first, and put a business-centric design process in place to avoid building flawed sites in the first place. "
Maybe. Site managers should evaluate - yes - but not in a userless vacuum. The place to do this is in the context of use - bring your users into the lab, set up a contextual inquiry, do something - anything - that involves users. Your site logs and support calls will tell you where to look and help you form your research questions. Your users, in the lab or in the "wild", will tell you what the problems are, and give you ideas of how to fix them.
Continuing:
"To avoid delivering site experiences that fall victim to the cumulative effects of many minor problems, site managers should evaluate the most important user paths, focus on fixing problems with well-known solutions first, and put a business-centric design process in place to avoid building flawed sites in the first place. "
This is a very "Inmates" type of approach. While it might seem like this is the best approach on the surface, I posit that perhaps solving one very large UX headache for your users might take the same amount of effort but provide a bigger bang for the buck, thus salvaging abandonments/improving conversions, than fixing only the easy, low-hanging fruit. Again, by understanding your users' context of use and looking at it from *their* perspective, you will be able to clearly see your priorities. Some of these items might be easier than others to fix, and some of them might have well-known solutions, but you need to address the items that are the most important to fix earlier in the game rather than later.
Finally:
"To avoid delivering site experiences that fall victim to the cumulative effects of many minor problems, site managers should evaluate the most important user paths, focus on fixing problems with well-known solutions first, and put a business-centric design process in place to avoid building flawed sites in the first place. "
This makes me want to tear my hair out. A business-centric design process will create sites that work for one constituency: the business. I can't think of many sites that have themselves as their primary audience. This sentence completely leaves their consumer - the user - out of the equation. Sure, they need to have internal processes that work - official processes and programs surrounding the definition of requirements and designs for their web sites, but in my world, if they don't bring the users in as stakeholders in that process, they are taking the long way around the block to find the solution to their problem, and that solution just might not work anyway.
Thinking like this means that if the organization is lucky enough to have a UX-focused role on their staff, this person is probably fighting tooth and nail to persuade the Forrester-reading folks of the dire need to have users evaluate designs prior to development. Simulation is probably not a part of this person's life. It's an uphill battle, this argument, because, well, the company paid for that article, automatically lending it credibility, and, well, Forrester is so well-respected in other areas, they wouldn't lie here. And so it becomes a battle for credibility for the UX role. Such a shame, because if companies like Forrester espoused a User-Centered Design process, as opposed to a business-centered design process, the Web might be a better place for everyone involved.