Field Notes Inside an Integrated Communications Agency

A co-worker shared a site with me that I find stunning: http://whatareyouwondering.com/. This site is meant to answer questions for new parents or soon to be parents.

At first glance I was overwhelmed with the beauty of the site. It's scalable and depricates well in many browsers. The concept is simple, but lovely. The questions are the content and the visual aspect of the site, is created by simply shadowing text. It is at once beautiful, human and content rich. 

However, when I began to play with the site I began to notice I did not like it as much. Do a search for crying. How many results do you get?

My first search resulted in 7, but only 3 questions. The rest were repeats.

I reduced the size of my browser window and I only received 4 results. I reduced it further and I receivd 3, but all three were not viewable on my screen.

If you click on a question, you go to the March of Dimes site to get more information. Is this beautiful site enough to get me engaged and then send me over to the real site where I can find more information? Will I be satisfied as a user?

What are your thoughts? How do you marry beauty and functionality? How would you make this better?

Personas are one of the most understandable deliverables in the user experience tool bag.  When used well design teams and clients empathize with the persona and develop an understanding of the user that is essential to great design.  I've often heard the word "persona" pluralized as both "personas" and "personae" and as a student of Latin, I tended to prefer the latter.  For those who don't know Latin: "ae" is the ending for plural nouns in the first declension (group of nouns that take the same endings) where "a" is the singular ending.  One of my colleagues pointed out that it really bothered him when people used "personae" in lieu of "personas" so I set out to figure out why "personas" is or is not correct.  Here's what I found.

First Stop: Merriam-Webster (online, of course)

Main Entry: per·so·na
Pronunciation:  \pər-ˈsō-nə, -ˌnä\
Function: noun
Inflected Form(s): plural per·so·nae  \-(ˌ)nē, -ˌnī\ or personas
Etymology: Latin
Date: 1909

1: a character assumed by an author in a written work
2a plural personas [New Latin, from Latin] : an individual's social facade or front that especially in the analytic psychology of C. G. Jung reflects the role in life the individual is playing
b: the personality that a person (as an actor or politician) projects in public : image
3 plural personae : a character in a fictional presentation (as a novel or play) —usually used in plural <comic personae>

Clearly us UXDs like the thought of having our work compared to the analytical work of Carl Jung, so the correct form must be "personas."  However, the definitions leave room for debate, because the personas that we use are fictional, but they're not literary characters.  They reflect the role an individual is playing, but not in real life, as the psychological approach suggests. What a quandry.

Second Stop: Boxes and Arrows (online peer-written UXD journal)

Search Term: persona (75 results)
Search Term: personas (155 results)
Search Term: personae (4 results)

It seems that the user experience community has an overwhelming preference for "personas" and that there's a few Latinists out there who just won't give up on the "ae."

I prefer "personas" because it's definition is, in my opinion, more in line with the work we do as UXDs and it is supported by the greater UX community, but I would like to hear your thoughts on the issue.  Any takers?

Experience design is a primary component in creating successful, high-performance Web sites.  We've come to learn this over the last few years mainly because of the plethora of Web sites available that are not optimized for the user.  But is this a new problem?  I don't believe so.  Since the beginning of design, there's been bad design and in many ways we need bad design to appreciate good design.  The lack of well-crafted experiences on the Web seems like a new problem because bad designs of the past didn't make it to the consumer.  Organizations were motivated by the high cost of producing stores, workspaces, brochures, reports and advertisements to make sure that they produced something of value to their audience.

I recently took a trip to IKEA, a worldwide home furnishings store, and instead of carrying a shopping bag I put on my UXD binoculars and made a few observations. 

Consistency

The first thing I noticed was a line of shopping carts and bags at the entrance.  The sign read something like "borrow one now if you like, but we'll have them right where you need them when you do."  This reminded me of providing a consistent set of controls on each page allowing users to search or contact a real person whenever they need to.

Call to action

In the showroom the aisles were marked with large blue arrows to remind you of which way you were heading.  This funnels shoppers through a guided tour of different household rooms showcasing IKEA products.  This is like having a clear call to action on each page.  It lets the user know exactly what to do next. 

A clearly labeled alternative

This semi-guided tour was long and prohibitive to running in and looking at only one part of the show room.  The folks at IKEA addressed this problem by providing shortcuts to other sections of the store, but not without proper warning.  Signs stated exactly what parts of the showroom you would miss seeing if you took the shortcut.  This is much like providing users with more than one choice on a page enabling them to explore and experience information instead of pushing it upon them. 

On the other hand, IKEA wants you to experience the entire showroom, so these shortcuts were a bit difficult to find.  Nevertheless it illustrates the need for good labeling and sufficient explanations to help users realize the results of selecting an option before they decide to click.

Contextual grouping

Pricing in the showroom was also clear; anything which was displayed in a group had an accompanying sign that told the total price of all items in the display.  This keeps users from having to figure things out on their own, because the information is readily available and contextually placed.

The right tool, right when you need it

There wasn't a lack of tools to help you make decisions.  Several racks were placed throughout the store with measuring tapes, pencils and notepads.  This touch resonated with me quite well.  It reminded me of configuration tools and wish lists in an online shopping site.  They're readily available and easy to use should you need them. 

Navigation just the way I like it

I must admit that this was my first IKEA trip, and I was feeling a little disappointed that the store was set up as a showroom.  I prefer to look at products by type instead of context.  I was hoping to see racks full of categorized products that I could choose from.  This was when they surprised me.  At the end of the showroom tour the helpful blue arrows pointed me to the "self-service area" full of categorized products, but not without a prominent warning on the floor that I might need a cart going forward.  This is not to say that everyone prefers items a type-based organization, but that it's helpful to see the products both contextually and categorically, and allow the visitor to choose one or both.

 

The dedication to a shopping experience is one of the things that makes an IKEA store unique and I think they have the right to call it "a major retail experience" as stated on their Web site.  So the next time you have a shopping experience, put on your UX binoculars and take note of the carefully crafted design, or lack thereof.

Thanks to Geoff our UXD Intern for making the trip with me on foot after a long day of traveling.  Expect to hear more of out insights this week as we attend Adaptive Path's UXIntensive in Minneapolis.

We frequently work with a local company to get interview recordings transcribed. We use transcripts of our stakeholder and user interviews as inputs into our design process. They help us to identify patterns from those we talk to which utlimately inform our stakeholder requirements and user needs and personae. Sometimes transcription works better than others.  Here are some tips:

• A transcript filled with "[inaudible]" notations is not helpful! Test your recorder and make sure you position it in the room appropriately to pick up all voices. (Consider background noise like loud A/C units since they may impact what gets picked up)
• Ask people to speak up if you think the tape may be missing their voice because of low volume.
• Consider giving the transcriber some assistance when you have frequently used jargon or internal terms. (We had a series of interviews on intranets and internets and the transcriber didn't know to pick up on the differences.)
• Voice the interviewer and interviewee names into the recorder before the session. This will help the transcriber track who's saying what. It also can be helpful if you have more than one interviewer and interviewee. (The typical male and female indicators in transcriptions can be very confusing when multiple people are involved.)
• If you are doing lots of interviews, identify the transcript and audio files by interviewee name instead of interview date. Sessions get cancelled and all those numbers make it difficult when trying to sort back through all of the results. 

If you've got tips, we'd love to hear them.

Ideally, this is first in a series of tips for UXD practitioners. Today's topic: interviewing.

We recently had a lot of stakeholder interviews to complete for a client in a short period of time. Think 65 interviews in a little over 3 weeks. Our interviews were more about buyin and garnering political support than stakeholder requirements, but nonetheless they had to be completed. We took a divide-and-conquer approach. This meant we had first time interviewers conducting interviews. Below are a few tips we created for the team:

• Avoid asking leading questions
• Ask people about recent behavior instead of predicting their actions: people are bad predictors.
• Avoid an inquisition: rather, aim for an organic and natural conversation
• Avoid jumping to solutions or feature ideas
• Listen! Listen! Listen!
• Restate answers to make sure you have understanding
• Ask for clarification of terms or items that you are not familiar with
• If you are not getting clear responses, PROBE!
• Avoid making judgments and assumptions
• Ask questions you think you already know the answer to: answers will surprise you.
• Do domain research before interviews to avoid getting up to speed on the subject matter during an interview.
• Listen for the words they use.
• Avoid getting a list of likes and dislikes. Ask why individuals have their preferences?
• Solicit stories thru "tell me about..." prompts.

Stay tuned for UXD Tip #2 - Transcription Advice

For Easter, we hosted family and friends at our house for lunch. Typically, we do it pot luck style everyone bringing a dish or two. This year, I decided to do an evite to coordinate the responses and who's bringing who and what.

I logged into Evite, picked an "easter-like" invitation template, entered my info, added my guests, made of list of items for them to select to bring with their RSVP and sent the invitations. To my disappointment, no one signed up to bring food and 3 people called me to ask me what time to come saying they couldn't find it on the invitation (even though it was there). I went back to the invite to see what the problem was. Here's what I found:

1) Poor Readability: Font color with event details too closely matched the background making the time of lunch nearly impossible to read. (The result, the individual bringing our ham arrived 45 minutes late!!!)

2)Improper grouping and ordering of response fields: "Please select something to bring" was below the "Will you attend" and comment fields (which is what people were expecting to do as part of their RSVP). The placement after ancillary "feature" fields like "I'm interested in carpooling" and "Email me when Guests Reply" makes the field even easier to miss.

3) Necessary fields not required: Since "Please select something to bring" wasn't required, when people didn't see it there was no prompt to remind them.

Here's a wireframe for my redesign of the invitation.

It features:

• Improved color contrast
• Re organized response fields (response and attendee acount fields related together)
• Inclusion of instructions in message body
• Addition of "add to ical" functionality
• Decreased emphasis in non essential "new" functionality.
• "Date" and "time" specific labels instead of generic "when" label

It's Friday, which means I'm debating the usefulness of wireframes again. Wireframes, for the new and uninitiated, are like "stick-figures" of a website. They indicate importance, organization and functionality of a UI but do so in a way that tries not to be too descriptive of the design. There's a certain amount of layout and organization that is implied, but we try to make sure that we don't tie designers' hands too much.

And it doesn't always work.

At capstrat , our designers and developers do some really powerful work. What's more, they get user experience and usability. So as a UX designer here, I'm in a position where steely control over the design isn't always necessary. In many cases, it's not appropriate since it impinges on designers' and developers' abilities to better deliver a product. Wireframes, unfortunately, can be seen as very prescriptive. Using them can minimize the contributions and expertise of people whose experience is essential to the design.

So, where does that leave us? Well, there are alternatives - page description diagrams being one. I won't go into them too deep here (you can read for yourself here), but suffice it to say that I'm underwhelmed with them. Mostly, they seem to be too vague. They're too prone to error and misinterpretation and are uneven on detail. What's more, they lack the basic information to communicate page-level organization and choreography. As a UX designer, I feel that page description diagrams simply abdicate way too much of what is my responsibility.

But wireframes are also good. They set boundaries of expectations to clients and are concrete in a way that prosaic descriptions can't match.

So, is there a middle ground? I think so, and here's an idea I've been banging around. I call it Pidgin.

Pidgineering

Pidgin dialects arise as a common ground between speakers of different languages. They mix terms from both and create a hybrid. I'm extending the analogy to UX deliverables. In this case, I'm interested in finding a common ground between designers, UXDers and developers. The goal is to create a vocabulary that conveys capability and choreography but is less prescriptive of the design. For the impatient, here's what it looks like:

Essentially, Pidgin is based upon three concepts: blocks, relationships and views. Here's the legend:

Blocks

The idea is to identify meaningful blocks of content and function, and show how they relate to one another. What's a block? Well, that's up to you, but essentially it's a distinct piece of function or content that can be usefully separated. A block is somewhere in the middle. So, a textfield probably wouldn't be a block, but a collection of fields and the submission button would be.

Relationships

Blocks relate to each other through relationships, which are...wait for it...lines. With arrows! Arrows describe the relationship; the pointy end shows what the block belongs to. By default, a single arrow means that the block will only occur one time for the other block.

There can be double arrows too. These indicate multiplicity: that a block can occur many times within another. In an article listing, for example, an article block might appear many times.

The lines themselves are either solid or dashed, indicating the block is required or optional respectively. If you want to get all crazy with it, you can use an open ended arrow to indicate multiple states of an object. Personally, I would discourage this except for trivial states of change. You're better off showing the default state and creating a storyboard for the block that shows how it acts in other situations.

Views

Remember when I said that content blocks related to one another? You might be thinking: but to what do they eventually relate? Views. A view is your page. It can inherit from more basic pages if you want, but that's not necessary. For example, you might abstract the global navigation and relate it to a more generic view. This is shown in the diagram above. Overall, though, a view aligns to an entry on your sitemap.

Is there a catch? There's gotta be a catch.

Yes, Virginia and it's something I'm wrestling with. Pidgins aren't testable-at least, not testable in a conventional sense. You could place this in front of a user and ask them to complete a task, but the results wouldn't be valid in the final design. You could get an idea of gaps and missing functionality, but not a whole lot more. You might be able to test each block, but that's really not useful either since it doesn't test the choreography, which is critical. As a tool to engage both development and design, however, pidgins seem useful in the early stages of the design lifecycle.

Thoughts?