Field Notes Inside an Integrated Communications Agency

For the past year our team of user experience designers has worked to find the best way to record and present our design strategy.  We, like many other interactive teams, use Visio to create site maps and wireframes.  Lately, we've delved into other tools for more interactive prototypes, but Visio still has its place in our reliable toolbox.  Anyone who's used Visio knows that it wasn't designed specifically for this purpose and our UX colleagues have provided several add-ons and enhancements to make it work better.  We've collected some of these, pulled them together, and made our own additions; now we have a consolidated template for our Visio diagrams.  We call it the Capstrat Diagramming Suite.

Here's a list of features for you.  We'll post a handful of articles over the next few weeks explaining how to use some of the key features.

• Templates for site maps and wireframes
• Extensive set of shapes, including common interactive widgets
• Annotation tacks for different audiences/purposes including development, design, copywriting and questions
• Ability to show/hide annotation tacks by type
• Ability to generate reports in Word with the annotations for easy printing
• Copy and paste remembering the X and Y position of elements for quick duplication of pages
• Ability to copy an entire page

That's just the short list.  If you're interested in giving it a try, you'll need Visio 2003 or 2007, but watch out if you're using both.  2007 makes some changes to the macros when it saves the file, so you'll have to do some spelunking into the Visual Basic settings to get it to work with 2003 again.  Let me know if you run into that problem and I'll lend a hand.

Download

ZIP File (0.98 MB)

Credits

Welie's Visio Macros, Martijn van Welie

Export to Word and Excel

Export All Pages as JPG, Chris Roth

Annotation Tack, Dan Brown

GUUI Prototyping Tool

Today is about making our world work better. It's the fourth year that the Usability Professionals Association has celebrated the second Thursday of November as World Usability Day.  The event was created to bring attention to usability and its importance in a technology-driven society.  Many local events are scheduled around the world today, including one here in RTP. This year the focus of the event is transportation and the UPA is sponsoring the Global Transport Challenge.  The goal is to encourage individuals to measure, monitor and minimize the carbon footprint of their travel.  While it might be a stretch, it's a great idea to talk about usability and sustainability in the same conversation.

To learn more about World Usability Day, visit the primary site at www.worldusabilityday.org or check out our local event at www.triupa.org.

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.

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?