Often times, UX teams are the baseball bats used by business and design teams to batter one another into submission. This is natural: UX research makes it a point to call out the good and the bad in a design, and other teams will hang on these findings to use them as ammunition against one another. At some point this is not the only kind of attention you want to be getting as it makes a UX team seem limited. Whether or not a team can move beyond that depends partly on the team and partly on the environment in which it operates. My personal experience has shown that the more restrictive a UX team lead is, the more likely a UX team is to be perceived as ‘limited’. (And in some instances, the more likely it is that team members are bored and unhappy.)

For instance, offering only design commentary is limiting because the UX team isn’t helping to solve the problems–or even encouraging solving the problems. Offering only design commentary is similar to being a trained monkey: You test a design, report the test results, and give the results to the project team. But what happens after that? What benefit does the UX team offer beyond “10 out of 12 users did X when on Y page?” Not a lot. The next time anyone will think of the UX team after that will be when they need to “prove” or “disprove” something to some other group in the organization. And after a while, project teams will begin to learn that certain things don’t work while certain others do–thereby making the UX team less useful.

So what’s my point here? My point is this: MAKE PROJECT TEAMS THINK. It’s very easy to report what you see in a study, and maybe occasionally point out some vague suggestion for improvement. However, it’s more interesting to start discussions around adapting designs to advancing technology, or revolutionizing existing designs by presenting common tasks in novel ways. As UXers, we should have some basic understanding of recent technological advancements, and be able to talk about what those advancements mean for design and user behavior. We should be fostering innovation if we want to get attention.

Yet this seems to be frowned upon by some team leads. To someone like me, who has worn the hats of information architect, interaction designer, and researcher, this is puzzling and frustrating. UXers should be strong in one particular area, but competent in others if they are to be truly effective as UX people. And demonstrating the ability to work with some reasonable competency in multiple areas–and speak intelligently about each area–is a way to gain the attention and respect of other teams. It’s a way of remaining relevant.

How is that bad?

While reading one of my many cooking magazines, I noticed an article about electronic winelists in some New York City restaurants. This interested me because paper lists can be hard to read. Either the light is too low for reading or the menu is mangled by previous patrons. Electronic devices emit their own light, which goes a long way toward making something readable in low light. And short of dropping or spilling liquid on an electronic device, there’s no dealing with semi-destroyed menus. So I searched for and found several online winelists. Some permitted people to select a wine and reserve it in advance of arriving at the restaurant, such as at ewinebook.com .

While looking over my search results, it occurred to me that it has been a while since I saw a good list. Within the past year I repeatedly user tested lists intended to guide users through important events. Then there were the countless transaction summary pages. In all cases users had trouble finding what they needed. Why? Three reasons: Difficult to understand content, illogical item ordering, and suboptimal structure.

So how does this relate to electronic winelists?

Think about this…On paper we’re limited to the basics: Name, year, winery, and cost. But give someone a backlit screen and it’s suddenly an invitation to create information overload. Sure, now restaurants can make the selection process easier by including images of labels, adding descriptions or recommendations, or checkboxes to mark the bottles patrons are considering. But how do you integrate that and still create a usable list?

A good place to start is remembering the main purpose of a list is the same no matter the display type: Summarize key information in an understandable way. Create concise bits of information and determine a logical presentation order. Then pin down structure. All of the other goodies like images, recommendations, or additional interaction mechanisms are add-ons that can compliment a list nicely when interjected at the appropriate points.

Item Content: Be Clear but Keep It Quick

When viewing a list, readers need to understand what is in front of them without needing anything additional. Therefore, two important qualities are clarity and brevity.

What makes a list item short and sweet depends upon its type. Actionable items within a list should be based around a verb. For example, “Insert tab A into slot B.” The action is clear (insert tab A into something) and the outcome is easy to predict (tab A will be in slot B). However, this same tactic does not hold when creating a list of facts. In this case, some content might require more explanation than others. For wine and drink lists this is an easy task. People want to know what they’re drinking, where it comes from, and how much it will set them back.

Structure: Complexity Relates to Visual Structure

List structure relates directly to a list’s complexity. By complexity I mean, do list items fall into multiple categories or not? Lists without categories should flow in a manner that makes sense. Classifying list items, however, requires you to determine the number of categories and their labels. Once all of that is established, determining hierarchy with good visual cues is next. The common ways of doing this on paper and electronic devices are the same: Indentation, text weight, font size, and color. Some lists also use graphics to denote main categories or special items.

I am sad to say that many list designs I have recently seen fall apart even more at this point. This might happen for a variety of reasons such as restrictions placed by the owner of the list content, or a lack of understanding about how we see lists. For our purposes today, let’s assume the latter.

At a basic level, we see lists as patterns: Lines repeating at a certain frequency. As with anything, if something repeats long enough we become desensitized toward it. So if the list is long enough then the eye becomes fatigued and the reader becomes less likely to see an item. Deviate from the pattern with bolded text or larger font for category labels and fatigue is delayed a bit. And bonus: Deviations also serve as fixation points for attention. So when searching a wine list, if you know you want a Malbec and not a Fume Blanc, then any deviations from the pattern of lines can help you quickly skip over whites and roses to reds.

Now that list design 101 is out of the way, we’ll next look at ewinebook.com to see how well it conforms to these ideas in addition to integrating all of the bells and whistles that make electronic winelists convenient for users.