Much ado about phone numbers

Four approaches to styling phone numbers.
Here are four approaches to styling phone numbers. Which looks best to you?

Lately I’ve been thinking about formatting phone numbers. Of course, there are plenty of options in addition to the ones above, but these are some common ones, although the thin spaces option is perhaps not too common. I added it because I’ve been wondering about the value of the separator characters, and if we can just not use them in favor of a little white space.

Here is some of the thinking.

  1. The conventional formatting of (123) 456-7890 will obviously be a phone number to most Americans.
  2. I’m no fan of the dashes.
  3. I’m okay with the periods. However, are they needed?
  4. Which led me to try the version with thin spaces between each set of digits.

I like the thin spaces, but I don’t dislike the conventional version. So, for obviousness, I lean towards the convention. For aesthetic, I lean towards the thin spaces.

But part of the decision of which approach to go with will depend upon the context. For instance, is the phone number labeled with an obvious word like Telephone or Phone? If so, I might opt for the thin spaces version.

However, if the context is unclear, say in the absence of clear cues about what that number is, the conventional approach would be best. Otherwise, the number could be misinterpreted as some other number, or it might simply take the reader too much mental effort to recognize it as a phone number. No need for that sort of rudeness.

Clearly, this is all just my opinion. Do you have a preference for how phone numbers ought to be styled?

A model for UX design reviews

Design reviews are so important for our work as user experience designers, but they too often fail us. Here is a model for design reviews that overcomes the problems of ego, emotion, and communication that so often get in the way of helpful feedback.

Alaina Kraus, Caitlin Potts, and I presented this process for the Jan 27, 2011 IxDA Lansing meeting.

Roles in the design review process

  1. Designer
  2. Facilitator (may also be a reviewer)
  3. Reviewers (you’ll need at least 2, but 6 may be too many)

Step 1: Designer explains the project and design concerns

At this step the designer shows the design (on paper, on screen, a prototype, etc.) and explains to the reviewers the context of this design. The designer should also point out specific areas that she wants feedback on.

Step 2: Reviewers discuss the design

This is the part that’s going to go against your habits.

The designer steps back and withdraws from the discussion. She should use body language to exclude herself to make it harder for the reviewers to address her. She should instead focus on her listening and note-taking.

Meanwhile, the reviewers are discussing the design amongst themselves. Instead of referring to the designer, they should refer to the design. Instead of talking to the designer, they should talk to each other.

Of course, the reviewers should point out good aspects of the design as well as discuss areas that they’d like to see improved.

By intentionally excluding the designer from this conversation, the dialogue can cover more ground and the feedback can be more honest. Otherwise, the dialogue has a good chance of focusing on a single point or so as the designer begins to explain or defend her decisions. That will derail good feedback, and everyone loses out on good information. People’s feelings are also at risk.

Step 3: The designer rejoins the conversation.

Finally, once the facilitator has determined the design has been discussed enough, he will invite the designer back into the discussion.

The designer can now summarize the notes she has taken in order to give the reviewers the opportunity to catch any misinterpretations. She can also ask follow up questions to clarify feedback she may not have fully understood.

The designer will probably want to defend the work or explain it, but really doesn’t have to. The goal is feedback for her, and at this point, she has it.

Why this method works

This method works because it makes it okay for the designer to simply listen in without feeling a need to defend her work. Likewise, it frees up the reviewers to not have to worry about hurting the designer’s feelings or fear the reaction of feedback taken poorly. While the method may feel a little awkward at first, after a few times it becomes easier.

What kinds of feedback make sense?

The reviewers should provide feedback that matches the fidelity of the design. This is to say, if it’s a rough sketch or task flow diagram, talking about pixel-perfect alignment of the layout is inappropriate. This should be obvious to most of us.

Also, instead of simply presenting your opinion about a design, discuss it in terms of usability heuristics (Nielsen’s list of 10, Tognazzini’s 1st principles document), accessibility concerns, visual design principles (e.g., proximity, alignment, repetition, contrast), and your observations from usability tests.

Where did this method come from?

In the mid-90s I worked at the Michigan State University Writing Center, and we used a similar process that we called the “fishbowl” to teach people to do peer-review writing workshops. In many ways, writing and designing are similar. When I started doing more design work, I recalled this process and adapted it to design reviews. It seems to work great. I credit learning this method from Dr. Sharon Thomas and Dr. Laura Julier of Michigan State University.

Update Feb 26, 2011: Wordcast live on Design Critique

Tim Keirnan over at the Design Critique podcast posted an interview we did on this process. Check it out! And thanks, Tim, for inviting me.

Update July 14, 2011: Michigan UPA workshop

This evening Alaina, Caitlin and I ran this workshop for a Michigan UPA event in Lansing. We had fun and it sounded like the attendees enjoyed themselves while learning this model. Thanks again Second Gear Coworking for letting us use your excellent venue!

Addendum to “Getting More From Analysis” by Lewandoswki and Dilworth

UX Magazine published Getting More From Analysis by Jared Lewandowski and John Dilworth on Dec 16, 2010. The authors provide a  summary of analysis as part of three design activities:

  1. Analysis
  2. Synthesis
  3. Evaluation

Diagramming these activities

They also provide some models for conceiving of these three activities, from linear to finally advising on a traditional equally-weighted 3-circle Venn diagram.

I like the thinking, and the clear reclassifying of design as including all of these activities, as opposed to only synthesis. However, their Venn diagram leaves direction out of the picture. I like this approach better.

Design as Venn diagram of Analysis, Synthesis, Evaluation, with clockwise arrows.

This model simply adds the arrows to what Lewandowski and Dilworth provided. It’s simple, but serves to organize the concepts.

Working together isn’t always simple

In addition, the authors recommend involving analysts in synthesis activities, and designers and developers in analysis activities. This, I agree, is good advice, but they didn’t provide any techniques to help you actually pull this off.

Analysis, synthesis, and evaluation each require different types of thinking, and a person specialized in, say, analysis may end up stepping on the toes of the people specialized in synthesis. The result may be a stunted synthesis activity, shut down because an analyst broke down the problem again before a designer or developer had a real chance to synthesize the ideas into various solutions.

To avoid these types of problems, creating intentional design (be they analysis, synthesis, or evaluation) sessions is important.

Setting up design facilitation sessions

I’ve been listening lately to some lectures by Professor Michael Roberto, and in them he’s advised what he calls the 4-Cs of encouraging real ideas in a debate. Roberto is focused on strategic decision making, but I think we can learn from this advice and apply similar thinking to how to set up design facilitation sessions.

  1. Composition – of group, who should be invited
  2. Context – Atmosphere, shared norms, ground rules, location
  3. Communication – How will we discuss and exchange views? E.g., subgroups, devil’s advocates.
  4. Control the process – Will I as leader be in the room? Do I ask for a packaged solution or do I ask to see a debate.

You might think this is over-thinking it all. Just put the people in the same room and have them discuss the design, and good things should happen right? Maybe. But why gamble? Even 10 minutes of planning a design session based on these 4-Cs could turn a waste of time into a breakthrough design session.

Thoughts on Richard Saul Wurman’s Why Design Now talk

Richard Saul Wurman, author of “Information Architects” and founder of the TED conference, spoke at the Cooper-Hewitt National Design Museum‘s “Why Design Now” event. This is that talk.

Wurman emphasizes that so much is designed, even the questions that we ask. To illustrate, at one point he asked Bill Moggridge, who was attending as the new director of the Cooper-Hewitt, how old he is. Bill answered the question, and Wurman pointed out, “Now we all know your age, but you know nothing new.” His point is that the power is in the question, not the answer.

That is worth ruminating on. From a design perspective, coming up with good questions to understand a problem is often difficult. It takes dialogue and exploration and work before you get to the good questions. And then you begin to understand the problem better. Wurman also points out in this talk that organizations too often jump to action before they really understand the problem.

Wurman packs a lot, including some humor, into this short talk. It’s worth watching.

Seams between systems and the Vignelli NYC subway map

I just read “Mr. Vignelli’s Map” by Michael Bierut over at Design Observer. In the post, Bierut remembers and analyzes why the public rejected Vignelli’s map of the New York City subway system. (Here’s the Vignelli subway map.)

The Vignelli map smartly acknowledged that for passengers of the subway focused on navigating the subway system itself, above ground geography was nothing but a factor of added complexity. So the map instead was oriented around the subway lines and stops themselves, abstracting actual geography. This was a keen simplification from an information design perspective.

But consider this observation from Bierut’s article.

To make the map work graphically meant that a few geographic liberties had to be taken. What about, for instance, the fact that the Vignelli map represented Central Park as a square, when in fact it is three times as long as it is wide? If you’re underground, of course, it doesn’t matter: there simply aren’t as many stops along Central Park as there are in midtown, so it requires less map space. But what if, for whatever reason, you wanted to get out at 59th Street and take a walk on a crisp fall evening? Imagine your surprise when you found yourself hiking for hours on a route that looked like it would take minutes on Vignelli’s map.

The concept of designing the seams between systems has become apparent within the user experience design community over the last couple years. This is an example of that problem of seams.

Passengers of the subway system are also navigators of the city itself, so their context of use spans beyond the subway and the end of their decisions are not merely which stop to get on and off of, but where they are going once they get out of the subway.

Bierut makes the point:

The problem, of course, was that Vignelli’s logical system came into conflict with another, equally logical system: the 1811 Commissioners’ Plan for Manhattan.

How can designers consider the seams between the subway system and the city plan to result in a better-designed subway map?

NYC, of course, has a functioning subway map. Is functionality the only litmus test?

(I’ve taken the subway in New York City only once, and managed to get from Point A to Point B successfully, although with some anxiety.)

Many stories in user experience

I just watched this TED talk, “Chimamanda Adichie: The danger of a single story.”

Please, take the 18 minutes to watch it, then continue to read.

Watching this talk brought to mind two thoughts related to user experience work.

First, in a recent edition of Interactions magazine there is an article “Stories that inspire action” by Gary Hirsch and Brad Robertson, that has planted the desire in me to uncover the stories of the company I work for, Covenant Eyes. There are so many ideas we have of ourselves, set by the expectations of management, employees, and so forth. But there are also stories of our customers, and by telling many of these stories, I suspect we will hear some stark contrasts that will cause us to reckon with ourselves.

Have we stereotyped our corporate self?

The second thought is in regards to personas. At Covenant Eyes, my colleague Jackie has taken the lead on creating a set of personas that we can use during our design and development work. This is a first for us. This week as we were reviewing the current set of about 16 personas, we were working on writing in various scenarios for each persona. I think the point of each scenario is to enrich the story of that persona.

But perhaps more important is that across the full set of personas, however large it may get, that we have properly balanced the stories that are represented by each persona. I think, at its root, that is part of why personas are valuable in the first place. To challenge the stereotype, the single story, that we might have in development about our “user.” These personas will be valuable if they can help us tell the many stories of our customers and users.