Jim Berney's Weblog: Interface Design Experiences

Designing the main and other primary pages for a site can be quite a challenge. Goals, priorities, and constraints all have to come together to develop a visual design concept for a project. Although you often hear designers complain when there isn't enough input from the sponsors to do their work, it can be just as bad when there's too much input from potentially the wrong stakeholders.

The content and visual design of the site's main page is critical. Within a few seconds of arriving at your site, users will develop a perception and mental model of what they can do and what they can't.

The interaction and visual designer's role in all cases is to gather, assimilate, and put forth a design that meets the desired goals and conveys the desired emotion to the user. Seems straightforward? In a perfect world, stakeholders from marketing, business, and management contribute into the goals and constraints that become the basis for site design. However, what if someone in a role of authority, but the wrong role to provide the information, overrides the information you have already received? This type of situation can be a reset for the designer, and can produce unsatisfactory results. A typical symptom is what I call "design thrashing", where the designer produces wireframe after wireframe, but nothing seems to click.

So how do you fix this situation? The first decision to make is do you continue to engage with the project? Is the situation fixable? If not, it may be best to move on, if possible. If so, it is critical for the designer to get back to basics and provide the leadership needed to nudge the team in the right direction. This is when the designer must open their trusty tool chest.

The first step is to get back to basics. Basics include a complete set of prioritized project and business goals, a profile of typical users (including their goals for coming to your site), and personnas for key user profiles that help bring the user to life. I've also found it useful to not only define what the project "is", but what it "isn't". Where are the boundaries? This should be a group exercise, not the designer going off on his/her own. Be sure that the most appropriate stakeholder(s) lead this effort. The designer's role is to facilitate and produce the artifacts. This shifts ownership of the artifacts to the responsible stakeholder, and makes it more difficult for another stakeholder to redirect the results. Everyone provides input, but at the end of the day, the appropriate stakeholder makes the decision and the team moves on.

Next, it can be useful to identify objects, color palettes, and examples of other sites that help express the "mood" or "emotion" that the site is to portray. Some designers use "mood boards" to narrow down what the team wants. You should obtain the same team buy-in, involvement, and acceptance as in the previous step.

Once you have these artifacts in place, get all the key stakeholders to buy off. This should be a formality. If not, the designer either really didn't have buy-in for the previous steps, or one of the cooks is trying the change the recipe. At this point, you must stop and work this out. If you attempt to proceed, "design thrashing" is in your future. Go back to the appropriate stakeholders. This may be marketing, business unit management, etc., but be sure that the best stakeholder leads the resolution, not you.

Once you have buy-in to the basics, the designer can get back to producing wireframes, visual concepts, etc., and the stakeholders can provide the necessary content. Although it doesn't end here, you are back on your way to a successful engagement.

I just got back from a Web Design conference in San Francisco titled "Voice that Matter". What attracted me to the conference was that most of the speakers were also authors, many of whom had authored books I had recently acquired. Thus, it struck me that this might be a different experience, and as expected, it was. It was a great three days that I would recommend to anyone interested in design, the web, and usability of the web experience.

Although I'll continue to blog about specifics I learned during the conference, I thought I'd dedicate my first blog to a few key take-aways.

I'll start with a comment from Steve Krug, author of "Don't Make Me Think", a usability best seller with over 225,000 copies sold worldwide. Steve said that you can learn everything you need to know about usability in a single 6 month semester course in college. Jakob Nielsen later talked about how usability conventions really don't change that much. Although user behavior changes, humans are adaptable, they learn, thus many of the conventions that were in place 10 years ago are still valid. As a usability professional and interaction designer, I'm wondering if a good chunk of my career has been relegated to a semester course in college.

What is becoming clear to me is that today's designers must wear a number of hats and have skills in multiple dimensions including usability, interaction design, visual design, and coding (html, css, javascript, ajax, etc.). The other trend becoming clear is that in the web space, groups are leaning away from the traditional waterfall development model and towards a faster methodology referred to as Agile Development. Agile methods promote short cycles and frequent iterations of design. This environment is ripe for more rapid approaches to usability and a method coined by Jakob Nielsen as discount usability. It should then come as no surprise that Steve Krug preached that everyone should run half-day usability studies each month with 3 participants, debrief your study over lunch, and identify 3-4 key issues that the team can reasonably fix. Even the tasks used to perform these studies were not considered that relevant. Steve commented that it probably doesn't matter which tasks you select, since you would get good feedback on most any set of tasks. Most usability professionals would probably take exception to this method, but the emphasis was on "doing usability" and "getting feedback from users" on a regular cadence, not planning a single, larger study.

So, you're probably wondering if I've lost my mind. No, because I understand that designing for usability involves skill and experience. However, for usability professionals who plan to make a difference in web design, it is clear that a broader skill set is required and that the focus really needs to be on design. Design that engages, fulfills our desires, and delivers a wow experience to the user. More on this as I decompress.