IA THINK

Simplicity

I recently started a food blog as an outlet for my long-standing interest in all things culinary (including, years ago, culinary school and career as a chef).  Along the way, I discovered two sites that highlight food-related content: Tastespotting and Foodbuzz. One I understood instantly and gain daily value from; the other, honestly, I'm still trying to wrap my head around.

Tastespotting

With Tastespotting, users submit blog posts or articles along with a representative image and a few lines of descriptive text. As entries are accepted by the editors, they appear on the Tastespotting home page:

(Oddly enough, when went to take this screen capture, my most recent blog post was in the first position on the home page.)

What I love about Tastepotting is that at a glance I can pick out a recipe (or other entry) that might be of interest. And, because the editors weed out weaker submissions, the content is of uniformly high quality. I've been submitting my blog posts to Tastespotting and I get a high volume of referral traffic from it.

Foodbuzz

Meanwhile, there's Foodbuzz, which seems like a cross between a social network and digg (recipes earn a buzz factor on a scale of 1-100). Here's the recipe page from foodbuzz:

I'd love to see eye-tracking data on this page. My eye immediately goes to avatars--in this case, the lime-green alligators.  It's hard for me to parse the page for a recipe that might be of interest. While the recipe titles are large and bold, the descriptive text is relatively minuscule compared to other elements on the page. Recipes never have accompanying images because it's not possible to include a photo when submitting. I get near-zero referral traffic from recipes I post on Foodbuzz.

Comparing the Visual Hierarchies

The Tastespotting home page has a crystal-clear visual hierarchy: there is one distinctive primary visual element (the images representing each submission). The purpose of the page is plainly obvious: to help the user discover new and interesting recipes.

On the Foodbuzz recipes page, there are more visually competing elements: the avatars, "buzz" buttons, foodie thumbnails, restaurant ratings.  What is the primary purpose of this page? I'd argue it's much less clear.

Achieving Simplicity

This comparison illustrates a problem I commonly encounter in the redesign work that I do: pages that visually don't declare their purpose strongly enough. Regardless of the content type, you can effectively communicate purpose using a strong visual hierarchy (giving the most important elements the most visual weight) and simplicity (eliminating unnecessary elements).

Simplicity seems to be the hardest to achieve in most real-world contexts. There is a tendency to provide "everything everywhere." You could argue that Foodbuzz is trying to accomplish more than Tastespotting, but in the end it may ultimately be accomplishing less. It's a site I want to like, but just can't seem to get my arms around it.

Handling Edge Cases

A recent post on the Blue Flavor blog about edge cases prompts this post. Also, I just completed a project that had team member (a developer) who I could have nicknamed “Mr. Edge Case.” So, I'd like to share my take, from a consulting perspective, on edge cases.

In my recent project, here is what would typically happen: I would present a design idea and usually before I even completed my explanation, this developer would ask about case xyz, where xyz was a situation I had not considered at all and on first blush seemed like a complete edge case.

My first task was to understand the scenario he presented. So, I'd stop and listen. Next, I'd query the team how frequently it occurred and/or how important it was to support in the system. Some discussion would ensue and we'd determine whether the case needed to be supported or not. An important question I would ask was: Does this case make sense given where we are going with the new design?  Sometimes, people carry forward old assumptions or ways of thinking about a problem. But, more often that not, the so-called edge case was a legitimate case that needed to be supported and so modifications to the design were required. Or, we could decide that case was one we could temporarily “put in the parking lot” for later consideration. Or, maybe we could throw out the case all together. This type of discussion is extremely common (at least in my world) because even on a months-long project I am not going to become the domain/system expert that my client is. The key is to partner with the client in a way that marries their expertise in their business to my expertise in user experience design. For that I need their complete intellectual engagement.

Here is what happened as this project progressed: the discussion we had about all these alternate cases deepened my understanding of the system. I got better at anticipating what may lie outside the happy day flow and so my initial design concepts became stronger. As a result of the tough questions Mr. Edge Case presented, I feel the overall quality of the solution was greatly improved.

In contrast, I've worked on projects where, for whatever reason, team members don't ask those tough questions. It always makes me nervous because design is seldom that easy. Sooner or later issues will pop up--and I'd much rather have them emerge sooner, when we can consider them early in the design process.

Blink Usability Highlights from 2007

My colleagues John, Jen, and Sim have a great new essay up on the Blink web site:

Staff Picks: Usability Highlights from 2007
Last year was a busy one for the Blink usability testing staff. It's once again time to reflect and report some of our favorite themes based on studies we completed in 2007...

Looking back at three years of Getting Things Done

In late 2004, I took the quiet time (work-wise) between Christmas and New Years to do a full-on implementation of GTD.

It's now been three full years since I've been using GTD, and while overall I've adhered to the basic principles, the depth of my implementation has waxed and waned somewhat. I tend to have periods on intense, single-focus work--particularly at the start of a new design project when I necessarily immerse myself in the client's business. During these periods, my GTD adherence wanes. But, then I come up for air, get clear, clean, and complete with the system and stick quite closely to the prescribed practices. I always feel more mentally clear when on "on" the system, but I seem to need those tunnel-vision periods in my work life to get lift off with a new client.

I remain convinced that the value of GTD, at least for me, is not in getting more done. It's in living an uncluttered existence, which helps me feel mentally more relaxed and focused. Interestingly, there was an article recently in the New York Times about the connection between mental health and physical clutter. I work and think better in uncluttered spaces (both mental and physical).

Tool-wise, I've gone through three phases:

• Phase I was Mac-based, using Entourage's Project Center for GTD, which I described here.
• When our office switched from Macs to PCs, I switched over the GTD Add-in for Outlook.
• This past year, I finally switched over to a web-based system so that I wasn't reliant on access to a laptop to get at my GTD set-up.

I went with Backpack and organized my projects by context--a page for each context (@Home, @Work, @Errands, @Internet, @Hobbies, @Someday). @Hobbies is really a sub-context of Home, but I found it worked better for me to put home management projects in one context and projects related to my main hobbies (knitting and photography) in another. I try to time-slice time at home so that I get a good balance of keeping things well-organized at home and doing things I enjoy. The organization of projects by contexts works for me because I find there is usually a 1:1 relationship between a project and a context. @Errands and @ Internet, however, don't contain projects--it's the place I put project next actions that require me to go some place (either in the physical world or the online world).

The other practice that is has been critical to my system (and which David Allen does not advocate) is creating a daily To-Do list. I LOVE these post-it note To-Do pads by Russell+Hazel. I have one pad on my desk at work; another pad on my desk at home. I use the pad to capture the "must dos" for the day--and it also serves as my idea capturing tool. At the end of the day, I go through the list; items are either done or not done--in which case I either do them right then or get them into my GTD system in Backpack.

I'm still the only person I know (in the non-online world) that uses some form of GTD. Sometimes, that's frustrating when I see someone who consistently lets things fall through the cracks. But I think organizing systems are something you are either on the bus with or not (I also follow the FlyLady system for household management). I am definitely on the organizing system bus. I need the structure and discipline to function effectively.

Overall, I'm very happy with my GTD setup and am looking forward to 2008 as another year of Getting Things Done.

Seeking fame and fortune on the Web

This week, Read/Write Web published a post (There's No Money In the Long Tail of the Blogosphere)  that articulates the challenges of making money on the Web with long-tail content.

Similarly, the ease with which content can be published to the online world seems to “democratize”  fame--where the highest-quality writing, music, acting, movie-making automatically bubbles up to the top of the heap.The perception vs. the reality of this was explored in an earlier article in New York Magazine: Blogs to Riches: the Haves and Have Nots of the Blogging Boom.

Nick Carr explores economics of blogging in his post When Economist Blog. As any economist realizes, there are opportunity costs associated with blogging. People with the ability to create the highest quality content also incur the highest opportunity costs when they blog. Nick wonders: “Does...the economics of blogging guarantee that only the mediocre and the worthless will survive - the ones whose time isn't particularly valuable to begin with?”

But, Seth Finkelstein, in commenting on Nick's post, points out factors beyond the economics that drive blogging behavior:

1) The lottery-like nature of the success argument.

Lotteries have negative expected value. This is very obvious. But people don't make good expected-value calculations overall (the ones that do, don't play lotteries!). This is apparent in the common evangelism marketing represented by the part about “actively demonstrating one's skillset for an interested public”. There are very few winners in that game. But an unlimited number of aspirants can be induced to buy a (losing) blog-ticket in hopes of becoming one of the lucky few.

2) The objects-in-mirror-are-smaller-than-they-appear

It's really easy to think that your blog is far more influential that it is. A niche celebrity will attract enough of an audience to seem impressive, even though objectively, it's likely not. But still, you can readily get the impression it's more effective than rationally justified.

3) Random reinforcement

The occasional high-attention hit is great for misleading the blogger that they matter.

Certainly we all know a person or two that devotes a seemingly uneconomical amount of time to some type of Web presence. In some cases, this is simply a hobby--done only for the joy of doing it and sharing with a few others. For others, it's done with the hope of hitting the big time. I've often wondered if the ability to publish content on the Web has overall fueled greater aspiration for fame and fortune--or if these aspirations are just more public and visible (and in earlier years would have simply manifested themselves through different channels).

True skill comes from working within constraints

I was a bit surprised to read this advice from Signal vs. Noise:

A great way to build a portfolio without clients is to make up fake clients... If you’re a designer you’ve got it easy. Design a few screens for your own fake online shoe store. Or online bank. Or cell phone company. Or grocery store. Show the world what you would do if you had the chance. I’ll guarantee your fake client portfolio will look better than your future actual client portfolio too.

I can't speak for other firms, but at Blink, a portfolio made up of fake clients will get you nowhere in our hiring process for design positions. I can image a fake client portfolio would look better than an actual client portfolio! Because in actual client work, the real skill comes from working effectively within constraints. Technical constraints. Organizational constraints. People constraints. If your portfolio doesn't demonstrate that you can work effectively under these conditions then your design "talent" has little real-world worth.

If you're just beginning, I'd suggest instead working with some non-profits to build a portfolio. Also consider starting in a usability position where you can gain project experience and get a foot in the door for a future design position. The great thing about starting in usability is that you observe first-hand how users respond to various design approaches.  I am forever grateful for the large amount of usability work I did at Blink when I first started seven years ago. It provided a great foundation on which to further build my design skills.

How Useful are User Interface Patterns?

I've got a new essay up on the Blink web site:

The promise of user interface patterns is alluring—the idea that you can solve a particular design problem by looking up the solution in a pattern library. In theory, designers use a pattern library to document user interface solutions, which are subsequently re-used by other designers. Despite the promise of patterns, as a working designer I have found the practical usefulness of patterns limited.

"Dialog Boxes are so 1999..."

In the past couple of weeks, some interesting job postings have landed in my email Inbox.

Job #1 included this requirement:

Have a keen understanding of user interaction issues and how to creatively address use challenges (“Dialog boxes are so 1999…”)

Job #2 was seeking the following:

Need the rare bird that plays in both worlds, someone who can stand up and contribute fresh ideas and not just a rock with lips executing off someone else’s plan. Want someone who doesn’t ponder drop-down list versus dialog box but instead comes up with a completely different model of interaction.

Setting aside the truly odd reference to "rock with lips," these seem to be pushing innovation for its own sake, rather than in the service of users. Many established design conventions (for both software user interfaces and in the physical world) exist because, quite simply, they work well. And even if they aren't optimized for the most efficient use (as with the QWERTY keyboard) users are so conditioned by the convention that changing it can create major barriers to use. For example, one thing most users currently expect is a page load/refresh when clicking a button or link on a web page. So when clicking a link doesn't behave this way, many people perceive this as "nothing happening." You can mitigate this risk by building in clear, strong feedback.  The key is understanding what design approaches constitute a risk--and methods can be used to mitigate the risk. Many times, it's just not worth introducing the risk--project resources can be better spent improving the core experience. There is a balance to achieve here--exploring using new modes to make tasks more efficient and enjoyable but at the same time avoiding unwarranted risks.

I understand what these postings are pushing for is a person unafraid to innovate, however, the tone and content of the posting may in effect attract young, less experienced designers. Though I’m not sure anyone would want to apply for Job 2 and risk being perceived as “a rock with lips.”

Actively Engaging with Requirements

At the start of many client engagements, I am faced with the task of wading through some type of requirements documentation. It can be a deadly boring task. And I know I'm not alone in feeling this way. Often I find the only person who really understands the requirements document is the person who authored it. Other team members either skim requirements or don't bother to really read them at all. I have come into projects were the client flat-out admits their developers don't read requirements.

The problem with written requirements is that people want to visualize how a system will work. Written descriptions of functionally pose the barrier of abstraction. It's difficult to make the leap from the written page to what users will actually experience. Sometimes, we are brought in simply to bring the requirements to life--turn them into screen flows that team members can review and discuss.

So what do you do when you are faced with some requirements tome? When you need to understand and internalize the functionality defined in the document? In this situation, I turn to mind-mapping.

Mind-mapping is handy for many things, but I find it particularly useful for capturing requirements in a more visual presentation. Mind-mapping allows you to pull out key elements and themes and visually draw connections between them. It's an important step to internalize the requirements--to understand the big picture of what the system is trying to achieve.

Below is a simplified mind-map (click image to view larger). Each branch contains a topic. Some topics have a notes icon indicated, which means additional text and/or graphic annotation is available for them.

I start building a requirements mind-map by adding “floating topics”--topics that aren't connected yet to another topic. Often, I'll add notes--pasting in key bits of text from the requirements document or writing my own description/observation. Gradually, as the system comes into view, I'll start making associations between topics. Sometimes, topics stay “floating” because associations aren't yet clear.

The key is that I am actively engaging with the requirements--not simply reading through them. It forces me to think about what's written and how concepts potentially connect to one another. You could do something similar with a white board and post-it notes. The advantage of using mind-mapping software is the ability to easily capture more detailed notes.

The mind-mapping software I use is MindManager 7. There is a Lite version for the PC for $99 that lacks the MS Office integration (including Visio export) contained in the $349 Pro version. What I like about MindManager 7 (PC version) is the ability to insert images into the notes for a topic. This can be handy when wanting to include screen captures or screen illustrations in topic notes. MindManager 7 is the only mind-mapping tool I've seen where you can insert images into notes.

There is a Mac version of MindManager 7 ($129) but, you can't insert images into notes as you can in the PC version. The Mac version also lacks any integration with MS Office (which may change with the release of Office 2008).

The requirements mind-map is intended for my use only. Rarely, I'll show it to clients just so they can see how I'm approaching requirements analysis. I certainly don't want them to review it as I'm not constructing it for an audience other than me.

Some Recent Essays

Here are a couple of essays I did for the Blink web site:

Consistency—when is it too much of a good thing?
Consistency in an interface is generally a good idea, but like many good things, it can be taken too far. Particularly in content-heavy web sites, pages with an overly similar look can make it difficult for users to get a sense of place.

Real-world user-centered design
How do you adopt and adapt UCD principles to real-world organizational constraints? It's a question we sometimes encounter in our consulting work. To get the ball rolling, we recommend three steps:

1. Understand the basic principles in user-centered design
2. Assess your organization's starting point
3. Use your starting point to strategize next steps