Static design processes lead to usability failures

Since my excursion to AEA ’09 in Boston I’ve been doing a lot of thinking about all of this “User Experience” stuff. Much of what Andy Clarke said in his Walls Come Tumbling Down presentation has been ringing around in my head, resonating with so much of my experiences over the last few years. Without diving into the entire presentations coverage of the current economic situation being a stimulator for workflow process change, I want to focus on a few thoughts from 1 slide in Andy’s presentation.

“Designers work on static look and feel visuals”

There is a design disconnect problem when the medium we publish to (the web) doesn’t match the medium we design in (static images). The web is dynamic, elastic, portable, modular and can be repurposed in any number of ways. Many web designers work in Photoshop and Fireworks to produce mockups that are static, rigid, not portable and often discarded after the initial design process. By designing in these static tools it is nearly impossible to answer the “what if?” type questions that we need to be asked in order to improve the efficiency of our design process and, most importantly, the usability of our websites and applications. What if the font size is increased by the user? How does that affect neighboring content? What happens if this column appears second in the markup? These things are all dynamic in nature and these questions cannot be effectively answered when the tool we use to produce mockups is static in nature.

“Designers and developers often work separately”

I firmly believe that if we are to improve the user experience of our applications that designers and developers need to work in harmony from the very beginning. Traditional “designer/ux” work processes such as paper prototyping, white-boarding and lo-fidelity mockup construction should be participated in by developers. In fact, the entire design process needs to have input from both designer and developers in order to be successful. Far too often designers pitch concepts and hi-fidelity mockups “over the wall” to developers once things have been finalized, creating a disconnect between the two; this promotes division and resentment. Designers often don’t understand the limitations that might be imposed given the technology that developers have been given to work with, and developers often don’t understand the usability considerations that went into design decisions. Developers might have insight into usability based on past experience that can go unheard because they aren’t included in the design process, and designers might know what the best way to develop a certain feature might be. (You can see how this could go on and on).

In a perfect world we’d all be designer/developers with the capability to have enough foresight to solve all these problems before they happen. Unfortunately this is not a perfect world and I’ve met only a handful of people who I’d consider equally developer and designer (it seems to be a rare combination for some reason). I think the solution to this disconnect isn’t that complicated though; mutual respect for each part of the process is a start. If design and development can co-exist with unburdened communication in the early stages of a project things will be in much better shape. Part of this has to do with breaking down the traditional barriers that seem to exist between these two disciplines, but I believe Kent Beck covers this subject in much more elegance than I would.

“Testing, by users and for browsers and accessibility comes last”

It’s interesting to me that the people we build websites and web applications for are often consulted last when it comes to design and usability considerations. Even when there are people on a project team who have usability experience it seems that _they_ are the ones consulted when really we should be pouring our initial efforts into getting feedback from potential users. It is so arrogant of us as designers/developers to make assumptions about what is “best for the user” without ever asking them. This can be a hard problem to tackle because many teams don’t have dedicated testers and some teams utilize developers to do nearly all of the functional testing. Developers _can_ test, but they aren’t the best testers in my opinion; developers are often working in an isolated area of a website/application and don’t have the “birds-eye view” required to really understand how all of the components fit together. When developers are the primary people doing user/functional testing, and this testing comes at the end of an iteration it can lead to design implementations that often overlook simple usability problems.

These problems are all solvable, they just involve a lot of open communication and respect between developers and designers and the willingness to abandon processes that are based on static models. The web is dynamic and we should be in our design/development methods as well.

Like this:

Related

6 Comments

Thanks for this post. It’s got me thinking of ways in which those who will use the website might be got in to projects right at the beginning. After all, it’s not just designers/developers who often think they know what’s best for the users. The clients themselves have often made a whole stack of judgements. I suppose recent “design by community” models such as the Drupal redesign are one approach…

Yeah I didn’t really even touch the whole client / vendor relationship, but you’re right that more than just designers/devs think they know what’s best for users. I’ve been guilty of it as well and I find the only way to really move on from that opinion is open communication at the start of a project (the Kent Beck video I linked is a great watch if you have the time).

Just my quick observation here but it seems like you are describing a web team with inadequate staffing. This is mostly based on how you are describing the developer as the person doing the usability testing, and the designer as the person doing to strategy and interaction design. True a lot of companies are consolidating resources in this bad economy but there is a point at when that consolidation comes with so much compromise that that web team essentially becomes ineffective. Which I believe is what you are describing here.

Ideally the designer would never have to think about the interaction design, this would be handled by a user experience designer who would do the high level (birds eye view as you called it) thinking on the project. Their deliverables would be static (wireframes) but they can also show interaction (storyboards, paper prototypes, etc as you mentioned). The user experience designer could and often does conduct usability tests on the application or website once finalized, but they also do initial testing before hand with HTML prototypes, paper prototypes, or even focus groups if there is nothing tangible for a user to test on.

The role of the user experience designer is critical to the success of a web team as much as having a manager or team lead is. Overlooking that role will simply just put the burden of that type of thinking on the designer or the developer. Now some designers and developers are really talented and have some level of UXD skills but often (as you said), it comes at a compromise to their other role of doing design or development. Just like how if there was no project manager the designers and developers would have to take on those duties if they like it or not, even if they dont know they are taking them on. If you ever asked yourself why do I have to spend so much of my time updating the client instead of designing or developing, then you are probably covering as ghost project manager.

Thanks for the observations Nick, I think you are accurate in your assessment of a web team with inadequate staffing. In my case, I don’t believe it’s a result of the economic situation as I live and work in Canada (in Saskatchewan) and we’ve been fairly insulated from the economic storm that’s been hammering the rest of the world. I absolutely agree that well defined roles that includes UX, IxD, and IA is important to the health of a successful web production team. From my experience with these (relatively) new terms it seems many businesses have yet to jump on board with these positions and so, as you said, developers end up covering as “ghost project managers” but also ghost ux, ia and ixd people as well.

In the past I’ve tried to drive our design processes down a path that involves more time spent on low-fidelity mockups and html prototypes than the traditional approach we seem to have taken involving statically produced, hi-fi mockups that are lobbed to a dev team for implementation. It’s tough to enact change you need to see happen in your team, but I’ll be damned if I’m not going to at least try 😉

You have a battle ahead of you for sure, its not easy getting companies to adopt proper consideration for user expeirence.. even if its just adding a interaction designer or something to the team. It can be done, there are more articles out there on “selling UX” than there are for nearly anything else with the exception of selling web standards perhaps.

As far as UX (both IA and IXD) deliverable being static. Yes, this is true, tho tools like OmniGraffle are allowing for more interactive experiences with the features in the newer releases. Some of them offer expeort as a XHTML click-thrus or functionality to show in-app click-thru demos. Other apps are surfacing that bridge the gap between wireframes and interactive prototypes. Check out iRise, Balsamiq, and Axure. Not all produce great XHTML at all, but it gets you a step closer for testing.