The minus sign in "-site" is the trick to excluding a website from Google search results.

This morning I found myself thinking about that perennial question of the reliability of Wikipedia. This time it is because my older daughter (she’s in junior high) is forbidden to use Wikipedia articles in papers for school, but she wasn’t given any other recommended suggestions from her teacher. So my observation is that she is now more likely to use online sources that are actually less reliable than Wikipedia.

Teacher: Your bias against crowd-sourced and curated knowledge has driven your students to find non-curated “knowledge.” Grade: F.

Better idea? Teach students to evaluate the credibility of online sources, and allow them to use Wikipedia articles if they are deemed sufficiently trustworthy. Mark down the grade if untrustworthy articles are referenced. This would teach a real research skill, and be more educational than just pointing to the Google search box.

But that’s a rant, and not what I learned.

I first did a Google search for “reliability of wikipedia,” and found a whole bunch of results. But they were mostly from Wikipedia. I looked at a few interesting Wikipedia articles on the topic, but wanted to see what websites other than Wikipedia had to say about this.

And there was my challenge. How do I do that same search but exclude results from wikipedia.org?

Well, I already knew that you can type site:domain.com into the search field to just search a specific website, so I tried site:-wikipedia.org. That didn’t return any results. So I tried another approach that did work, putting the minus sign to the left of “site,” and it worked like a charm.

reliability of wikipedia -site:wikipedia.org

There. I learned something new today.

Why would I join this group versus that one?

Some are tied to specific organizations, like the Information Architecture Institute, the Interaction Design Association, or the Usability Professionals Association. Or like the Boxes and Arrows group, related to a specific industry publication. If you are a member of such an organization, joining the matching LinkedIn group probably makes sense in some way.

Some are focused on narrower subjects, like the Agile Experience group or mobileUX. If you have a narrower interest and find a group that fits, perfect.

Some differentiate by being localized. The UPA Israel, for instance, or London User Experience Professionals. Cadius is a group for UX people who speak Spanish. I think that’s fantastic.

But then we have all those other groups that ooze together, subject-wise. I’ll bet each has its own creation story, but at this point, the differentiation is slim.

Don’t these top 5 UX LinkedIn groups sound similar?

1. User Experience
2. Interaction Design Association
3. UX Professionals
4. UX Professionals Network
5. User Experience Group

The second item is the group for members of IxDA, but the rest are simply professional groups for UX people. I’ll bet if you mixed together all the content and members of those groups you would first see a lot of repetition in members and topics, and second, I’ll bet you couldn’t separate them back into their original groups without a key. What does that say about these groups?

Some data on these groups

For what it’s worth, I’ll post some data I harvested while trawling LinkedIn this afternoon. (Why did I do this? Am I mad? No, but I’ve been sick all weekend, and in my addled state, cataloging some LinkedIn groups was the most obvious thing to do.)

The following data is merely what I found this afternoon. It is not comprehensive.

Chart showing membership rates of about 40 user experience groups on LinkedIn as of March 11, 2012.

Want a little more information? You can download an Excel spreadsheet I used while gathering this information. The worksheet includes columns for ID, Title, Membership, Parent Group, Created date, Type (e.g., Professional Group), Owner, Coverage (e.g., Earth, Greater London, UK, etc.), Language (didn’t fill that in), and Organization (e.g., IxDA).

Here’s the Excel file: User Experience (UX) groups on LinkedIn, March 2012 (.xslx)

Too many groups!

In closing, I think it would be easier and less time consuming to stay up-to-date in the field if there weren’t so many overlapping groups. What if some of these groups merged? Would people get too upset about that?

(Now for more tea and expectorants.)

1. Remember, you don’t need this job. You need a job, but not this one.

In my first full-time, salaried position, my boss shared this nugget of wisdom with me. (He shared the next one too.) I had to chew on this one for a bit, repeating it to myself in different ways for it to sink in. But once it did, it changed how I looked at my job.

The biggest change is that it removed a fear. I didn’t fear losing the job, because, after all, I didn’t need this job. With that gone, my attitude shifted to where I was willingly giving my time to the job. It was my choice to work there, so in a way, it gave me back some power, emotionally. I wasn’t dependent on the job, and I wasn’t begging for the chance to do that job. Instead, I had the freedom to focus instead on what I needed to in order to get the job done.

It also has helped me to not worry about the inevitable politics of an office, and instead more clearly relate to the people I work with. It helps me better respect my colleagues as the human beings we all are.

There is a simple, yet powerful, proverb that stands hand-in-hand with this pointer: “Do you work heartily as for the Lord rather than for men.” Attitude-wise, taking this proverb seriously means that I crave honor from God, not from my boss, coworkers, clients, or employees. This has been profound for me, and I encourage all who read this to take this proverb to heart.

This first pointer is probably the biggest of these for me.

2. If you want to seem invaluable, find a problem and solve it. See a vacuum? Fill it.

This one is obviously simple, I think, but sometimes I wonder if it just hasn’t occurred to people. If you want to be valuable, do something valuable. Keep your eyes open for that thing that clearly needs doing that you have a shot at doing, and figure it out. If it happens to make sense with your job description, great. If not, just do it anyway.

3. A secret part of your job is to make your boss look good.

This is an interesting one because it still applies when you aren’t happy with your boss.

How do you do this one? You give your boss credit for good work, good decisions, whatever, to others. You don’t have to overdo it, but keep it in mind. Also, I’ve been in situations where I’ve been asked to help prepare a presentation or a proposal for my boss, and even though I may not be the one delivering the presentation, I can try to make sure that my boss will seem  organized, coherent, and smart.

This pointer is helpful because, by making this part of my job, it forces me to check myself when I have a bad attitude about the person I report to.

4. Bring an alternate idea along when you bring a critique. (And if you can’t, then think twice about offering your critique.)

The point of feedback, of critique, is to make something better. I get the feeling that people forget this, and think that the point of critique is to look smart, to make someone else look dumb, and to thrill in the dark joy of shredding someone else’s work.

So, if the point of critique is to make something better, doesn’t it make sense to point out a problem and immediately follow it with at least one idea to overcome that problem? Maybe it isn’t the idea that will be chosen, but by offering that idea, you make yourself a collaborator with the person who receives the critique. You offering an idea can spur more creative thinking on the problem. Plus, offering an idea is brave, because your idea can now receive critique. If all you ever do is critique but never add ideas, you’re probably a coward and are making things worse, not better.

Closing

I know there are all kinds of other thoughts on work that I have, and I’m sure many of my blog readers have their own life lessons to share.

Please comment with your reactions or additions!

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

Relative sizes of twin, full (double), queen, and king mattresses.

My current mattress is a little too soft for my bad back’s liking. And it’s just too big. I’m decidedly single at this point, have never been too tied to possessions in general, and so for me my queen mattress is just a nervous tick on the side of crazy. It’s time to downsize.

So, I wanted a picture of the relative sizes of standard mattresses to help me think through this. Tada, OmniGraffle to the rescue. Picture attached. (I realize they look like sticky notes. Mildly funny to me.)

Looks like a full-size mattress will be in my future.

As I’ve been finding out, it would certainly be easier to just skip it. This past summer I hired a nanny for about six weeks. And, wanting to do the right thing, I decided I would deal with the paperwork and expense, and just pay her as a household employee and deal with the taxes. And that’s still the right thing to do.

But, wow, do I hate paperwork, and this stuff is over the top.

Form 518 from the State of Michigan was a bit over the top. I just wanted to pay taxes for hiring a nanny for a few weeks.

For the State of Michigan, I found out I have to fill out form 518, Registration for Michigan Business Taxes. The title of the form alone caused some trepidation. As I proceeded to fill it out, I found myself frequently scratching my head, thinking things like, “Why are they asking me about acquiring a business in the past four years? I just wanted to pay taxes for hiring a nanny.” Or, “But I’m not a business. I’m not buying or selling anything. This is a money losing scenario for me. I just want to pay what I have to for hiring a nanny!”

So, there was form 518, plus two additional forms I had to fill out, just to jump through some hoops to register for Unemployment Insurance taxes.

It’s pretty obvious that those forms are meant for real businesses, not private individuals who want to pay a household employee. I was so close to hiring a lawyer or accountant, but that just seemed unreasonable to me, so out of proportion with the fact that I just wanted to pay a nanny.

Upon having gone through the paperwork, nearly all of it was completely irrelevant. The relevant pieces were mostly my name and address or oddly specific. For instance, I nearly didn’t find the SIC number that applies to my situation. On the second page of SIC codes, about two thirds of the way down the fourth column of codes I found 881: Private Households – Domestic Employees, Cleaning, Baby-sitting, Private Nursing. I’m glad I found it, because I was really close to just leaving that field on the form blank.

Perhaps to the government, paying a nanny is just like owning a business. But, to me that seems like a dandy of a one-size-fits-all blunder. If instead the only form that a private individual had to fill out in order to register for nanny taxes was a quarter-sheet size form with contact information, perhaps more people would actually fill it out.

Maybe it could be a special edition of the 518, called 518-PH, for Private Households. The rest of the pertinent 518 information could be presumed on that form, simply because people filling it out fit that profile. (For instance, it would imply SIC # 881.)

How many people looked at the paperwork, freaked out for a moment, and then just decided to skip it? The current form is quite simply a roadblock to tax revenue and to people who would like to do the right thing.

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?

Which groups?

• Usability Professionals Association, Michigan chapter (MI UPA)
• Interaction Design Association (IxDA), local groups
  • IxDA-Ann Arbor
  • IxDA-Lansing
  • IxDA-Grand Rapids
• Michigan CHI (MichiCHI)

Each group organizes events for practitioners, students, and academics to gather together in order to network and learn from each other. It’s great!

But it is also a bit much to keep track of, and I’m not always clear on which group is sponsoring which event. After all, a great many people in the UX field do usability research and evaluation, interaction design, and are interested in research and theory. Thus, we tend to see a lot of overlap in attendees for events from any of these organizations.

So, during a conversation at work today, Caitlin, Alaina, and I hatched a rough concept. (Disclaimer: this post represents what I personally took away from that conversation. I invite Alaina and Caitlin to chime in on the comments below to correct my thinking and/or to add to this post.)

Here’s the gist: Loosely coordinate the efforts of these organizations by factors of geography, frequency, and approach to UX.

Factor: Geography

MI UPA is a state-wide association, so we hope that MI UPA events will be big enough to draw people from a wider area of Michigan. Of course, it is difficult to draw people from as far north as the Upper Peninsula (there are UXers up there, right?), but for a great deal of people in the state, an occassional drive to Lansing, Ann Arbor, Detroit, or Grand Rapids is acceptable if the event will be good enough.

However, IxDA is based on local groups. IxDA-Lansing, for instance, tends to draw people from the Lansing area and nearby areas like Owosso and Flint. IxDA-Grand Rapids will likewise draw people from that area.

MichiCHI is similar in geographic reach to MI UPA.

Factor: Frequency

Because of the geographic constraints, having frequent meetings is easier for IxDA local groups because attendees simply don’t have to drive that far. So, IxDA groups could meet monthly with greater ease, and they would be more relaxed.

However, because people would need to drive further to attend events by the statewide organizations, they could do better to meet perhaps quarterly or even less, leaving the more frequent get-togethers to the IxDA local groups. The expectation is that these less frequent events would be a bit more polished—more of an event than a meet up.

Factor: Approach to UX

What I mean by this phrase is whether the UX focus is more academic (MichiCHI), more focused on usability work (MI UPA), or more focused on interaction design (IxDA). Of course, because we’re all in the same general field, this breakdown should be taken with a pretty heavy grain of salt. But while we tend to operate as generalists in part, I personally appreciate opportunities in each area, so I think there is value in this distinction.

Coordinating events by these various groups

Sketch of idea for coordinating MI UPA, MichiCHI, and IxDA local groups in Michigan.

So, given these thoughts, here’s a proposal.

1. We embrace the IxDA local groups

Perhaps we could even create more. How about an IxDA-Detroit? IxDA-Marquette? IxDA-Houghton? (Trying to represent the U.P.) These IxDA groups would sate our appetite to meet frequently for networking, idea sharing, and teaching each other how we can do our work better. In the meantime, MI UPA and MichiCHI purposely slow down the pace and encourage participation in the more frequent IxDA events.

2. we help the state associations with less frequent, more formal events

These frequent IxDA groups can help generate the presentations that could then be shared state-wide at larger events sponsored by MI UPA or MichiCHI. The coordinators of each IxDA group could stay in touch with the events committees of MI UPA and MichiCHi and recommend excellent presentations. And these IxDA groups would help promote and recruit volunteers for the larger events put on by MI UPA and MichiCHI. These organizations are already putting on some awesome events like the annual Internet User Experience conference. Let’s pitch in and help them be even more awesome.

And how to coordinate between MI UPA and MichiCHI?

Beats me. Perhaps some of you have ideas?

Conclusion

We have a really great group of practitioners in Michigan, and we’re lucky to have these organizations actively promoting our field. With a little coordination for each group in light of the others, I think we can tune our professional organizations to work even better together.

Do you do UX work in Michigan? What are your thoughts?

The utm_medium is pretty straightforward in that the medium would be values like email, web, twitter, rss, and so on.

But, what’s the difference between utm_source and utm_campaign?

Google’s documentation on these variables is helpful in general, but is not all that clear on the difference between these two variables.

So, here’s how I think of those variables. The utm_source is like a noun, and utm_campaign is like an adjective. The utm_source will be more consistent from one edition to another, while the utm_campaign will change.

Let’s look at an example. Let’s say I send an e-mail newsletter called Brilliant Widgets every season (Spring, Summer, Fall, and Winter), and I want to track how many links back to my website each edition generates. Here are the utm_* values I would use.

utm_* values for the Winter edition of Brilliant Widgets

So, the href value of the link back to my website would look like this: http://blog.davingranroth.com/?utm_source=Brilliant_Widgets&utm_campaign=Winter_2011&utm_medium=email

Now, assuming I use those parameters on the links back to my website and that my website activity is being tracked with Google Analytics, I’ll be able use Google Analytics to identify website visits that came from that e-mail newsletter. Then for the next edition, I would keep utm_source and utm_medium the same, but update to utm_campaign=Spring_2012.

With this thinking, you could define a set of values for all the e-mails you send out, and create a system that would help you know what those values should be when you introduce new online publications.

I’m sure that other people and companies have come up with their own approaches to using these utm_* values.

I’m curious, does anyone else have different ideas or examples to share?

This steak, spinach, onion, tomato, and avacado spread sandwich with fresh tomato soup made a tasty dinner.

I got the idea for the sandwich from an article on LiveStrong.com and I decided to track down a tomato soup recipe to make something of my abundant backyard tomato plant. No kidding, it was the best tomato soup I’ve ever had in my life.

Taqhuamenon Falls

We took a leisurely drive up and spent a morning site-seeing in Taqhuamenon Falls State Park. If you visit the park, the brew pub at the upper falls serves some tasty grub!

An evening at Abigail’s parents’ beach house near Keewenaw Bay

We picked up pizzas and root beer one evening and headed to Abigail’s family’s beach house on Lake Superior. Abigail is my brother Peter’s girlfriend. We had a stone skipping contest, my brothers disappeared in kayaks for a while, and we roasted marshmallows as the sun set.

White City lighthouse and beach at Jacobsville

After a nearly fruitless evening looking for thimbleberries, we headed to the beach at Jacobsville. One of my young cousins here took a weather-cleaned bone as a souvenir from the remains of a bald eagle’s meal out on the walk to the lighthouse.

Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.

Here’s why. Because for small-caps to work, you need to start with lowercase letters.

However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.

So, when you tried small-caps, it simply didn’t work. For example, see this web page from 2005 that Joe Clark wrote to test small-caps. Note how the small-caps versions are more like regular capital letters. Not cool. It makes the hack look good, which is bad.

So, here’s what you can do (and what I think browsers ought to be doing automatically anyway):

1. First apply text-transform: lowercase
2. Then apply font-variant: small-caps

That ought to do it.

Here’s a more specific example of the CSS.

abbr, acronym {
text-transform: lowercase;
font-variant: small-caps;
letter-spacing: 1px;
}

We all know the <br /> tag is used to insert a line break in HTML. But what we’ve been missing is that we were too often after something else. Let me explain.

Common reasons to use line breaks

Why would a web writer interrupt a passage of text with a forced line break? Here are a few possibilities.

• Trying to avoid an orphan
• Inserting a line break before a 2-word proper noun, like “American Airlines,” so the noun isn’t split
• Formatting content like a mailing address

The problem with line breaks (<br /> tags)

Forcing a line to break in a document that will be printed is a no-brainer. But web writing has different constraints that we shouldn’t ignore.

Copy on the web has the luxury and burden of being portable. That text can show up anywhere:

• in an e-mail message
• on some other web page
• in an RSS reader
• copied and pasted into a Tweet
• in a web browser on a mobile phone

This means that the line length you wrote your text for is simply not reliable. You need to consider how that text will show up in other places too, at unknown line lengths.

A line break may look fine on your screen, but it might look really awkward when that text appears somewhere else beyond your control.

Instead of splitting text, stick text together

Orphans

Avoid orphans especially where the text is most likely to appear, but relax. You can’t prevent them altogether.

Instead of inserting a line break, opt to rephrase the text to change the length and prevent the orphan. But realize that when that text appears elsewhere, it might just have an orphan.

You also have the option of a special white-space character called a non-breaking space. In HTML, it looks like this:  . When you put a non-breaking space between two words, those two words will always be on the same line of text.

2+ word proper nouns

If you want to be sure that “American Airlines” remains on the same line in body text, employ a sprinkle of CSS magic. In the markup, a corporate name should be contained within a span element, like this:

<span class="brand_name">American Airlines</span>

And then to make sure that those two words stay on the same line, add a line like this to your CSS file.

.brand_name {white-space: nowrap;}

That will prevent the brand name text from being split at the end of a line. Instead, both words will flip to the next line if there is not enough room for them on the current line of text.

Formatting content like mailing addresses

In this case, I’m actually okay with using <br /> tags. But, left to my own devices, I might use some different markup and some CSS instead.

Let’s say we have an address like this fictional one.

You could just put that text in an address element and use line breaks.

Or you could mark it up in the hcard microformat, and then think about styling it based on that markup. So, it might instead be coded like this.

<address class="vcard">
<span class="fn">Samuel Clemens</span>
<span class="street-address">1835 Huckleberry Row</span>
<span class="locality">Hannibal</span>,
<abbr title="Missouri" class="region">MO</abbr>
<span class="postal-code">63401</span>
</address>

And then a little bit of CSS like this would take care of the line breaks.

.vcard .fn,
.vcard .street-address{
display: block;
}

The point: we overuse line breaks because they don’t require any extra thought

Instead, let’s consider why we actually want a line break the next time we go to use one. There’s probably a better option once you realize that you don’t actually want to break a line of text, you really just want some of the text to stick together.

Jan 27, 2011 - I had the pleasure of sharing this design review method at an IxDA Lansing meeting. Here are designers practicing this method. Photocredit: Chris Bachelder.

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!