Seen & Learned

Establishing Qualitative Criteria for IA and UX in One Fell Swoop: How to Conduct a Card Sort with Storytelling

2010-07-22T18:20:00.001-07:00

Slides from a presentation we did at the Boston Mini UPA conference in June 2010. "Card Sorts with Storytelling" is how we describe the type of research we started doing with site users for MIT Medical in 2008. We combined methods – a card sort, careful questioning and task completion – into a protocol to get information to inform site map, feature and overall IA decision-making, which was stuck due to lack of team consensus. The sessions were successful, and the results were extremely helpful in helping the team focus on making the site as useful as possible for the MIT community.

We refined and repeated the format on several higher-ed projects with similar success. This practice is not intended to replace more rigorous testing, but rather to quickly provide a project team and visual designers with user information when there otherwise would be none.

Establishing Qualitative Criteria for IA and UX in One Fell Swoop -- How to Conduct a Card Sort with Storytelling

View more presentations from Nimble Partners.

User experience design overview for Tufts' School of Medicine web health communication class

2010-07-22T12:43:00.001-07:00

Slides from my talk at Lisa Gualtieri's class at Tufts University SOM. Created for health communication students to give them an overview of design activities and the process of designing sites and apps.

User experience design overview for Tufts' School of Medicine web health communication class

View more presentations from Nimble Partners.

Making "Support" helpful - some tips for Twitter

2010-07-06T16:05:00.000-07:00

We all run into problems now and then using technology – heck, I'm a pretty tech-savvy person myself, and even I sometimes have to contact tech support. And when I do, there is nothing I find more infuriating and representative of poor customer support practices and user experience than hiding vital support information.

Consider a recent example of this: we're having problems getting our tweets to load on the Nimble Partners home page. I've worked tech support myself, so I know that the first step is to try to reproduce the bug and isolate the problem. Since nothing about our code had changed, and nothing about seaofclouds' script had changed either, I suspected the problem was with our Twitter stream. This was easily tested by successfully loading another public Twitter stream onto our home page.

So, now I knew that @nimblepartners was the most likely source of error. Next thing to do: check Twitter's support documentation and Google for potential explanations. I couldn't find anything, so finally I realized I'd have to file a support ticket. Twitter's support website allows you to log in and check the status of your current tickets, but there's one critically important thing it doesn't easily let you do: file a ticket.

That's right: you can spend all day looking through the otherwise well-designed ticket review pages, but if there's an obvious link to file a ticket, I never found one. After many frustrating minutes, I finally gave up and Googled for how to file a ticket, which eventually got me the right link – on an externally hosted site totally separate from Twitter's Support site. (Update: days later, I discovered that FAQs about account abuse and a small selection of other issues have links to the ticket form – but there's no consistent placement for or treatment of a link area.)

I understand why companies want to drive customers to online documentation: it's vastly cheaper than having a human provide assistance, and most of the time, a good FAQ will solve most of the problems. But there's no reason to hide or bury vital contact information – all this does is annoy your user base, and for a company like Twitter that seems to pride itself on interface simplicity and a friendly, inviting user experience, this kind of hide-and-seek game is antithetical to the way they're trying to present themselves.

One possible solution: make the link available on support FAQ pages as part of a consistently placed and worded "did this answer help you?" area at the end of each question. This hides the link from the casual emailer who rarely bothers to click into or read the support questions, but still makes it available for people who genuinely need assistance. Ultimately, it's counterproductive to annoy customers by implying you don't want to talk to them – an ironic result for a company whose basic mission is to promote communication.

A Tip for Visual and Information Design from the Movies

2010-03-19T06:38:00.000-07:00

About this time of year I participate in the AIGA's student portfolio review. Graduating designers pay for the "privilege" of showing their work to as many volunteer professionals as possible within a set time limit. As a reviewer, the heat is on to grasp a student's capabilities in a nanosecond and impart some wisdom that will magically help them transform their portfolio into a thing of power and beauty that will make jaded design hiring managers weep with awe.

These brave and determined kids have paid through the nose for college, paid quite a bit of beer money to be critiqued, and fairly enough, have high expectations of the event. The work varies. In a room of about 16, there are a few standouts. For one or maybe two, it is hard to believe that they had formal design education. Last year I was faced with a portfolio that the student should have been able to use to get a refund from his college, or at least a free extra year. College doesn't work that way, unfortunately, and I had to figure out something constructive to say, fast.

The student used his own illustrations as backgrounds to several CD packages and action movie posters. The illustrations were graffiti-like and the type was big and bold. Overall, the work was a visual explosion, not in a cool way. I started talking about movies – about how in action movies there's a star and a best supporting actor or two. Visual design is like that. You can think of what you are designing as a movie with a cast. To tell the story, there may be a headlining star above everyone else – they are the most important thing. In a comedy or period piece there may be an ensemble cast and the setting may play a key role. In a buddy film there are two stars who are usually very different, and it's the chemistry between them that makes the movie interesting. When you think about your poster or site or whatever as having a cast, and you identify elements of the design in terms of a cast of characters with "roles," it forces you to think about hierarchy and the relationship between elements, which is a good thing. When a film has a lot of big stars, the script has to be written to use them wisely, where they have the most impact.

My student nodded like I was speaking a language that he understood, which made me feel relieved. I have no idea how he's fared, but I used the movie analogy yesterday to help get myself unstuck on a website design. It has helped me, and I really hope it has helped him.

Why we don't design for "Innovation"

2009-09-18T10:46:00.001-07:00

We love technology and the things it can help us do. We are excited by the new functionality and resources we see everyday. However, we regularly see and hear from people who wish the technology they already have met their needs better. Thinking back over our most recent research sessions the participants - executives, students and reporters - all want to access information that addresses their needs in a way that's easy to find.

Solving some of these problems is pretty easy, like designing a faceted search, creating a comprehensive structure for information and designing type and imagery that supports the content. Solving others can be tricky politically, like providing the names of appropriate people to contact if needed (creating transparency). A few more solutions can be time consuming, like developing summaries for a database of long documents or enabling personalization. All of these are manageable, however, and provide a significantly improved user experience.

It would be amazing to develop the next big thing, but we see a lot of room for improved user experiences using the tools we and our clients already have. Learning about what matters to people and providing it quickly and manageably never gets old.

User scenarios beyond the web

2010-02-15T12:59:00.000-08:00

User scenarios have been widely adopted by web designers as a useful tool for helping ensure sites provide what visitors need and expect. Less well-known is that they are also a great tool for ensuring offline communications do the same.

Recently I was in Sears. They have created central checkout kiosks at my local store (Cambridge, MA) which is a step forward, because previously, it was impossible to find a cash register and a salesperson at the same time. Now there's a large checkout hub at the exit/entrance to the connecting mall. When I entered the store I came from downstairs – not from the mall. I did not pass a kiosk. I shopped and could not find where to pay. I looked for signs, and found this (pardon the fuzzy, surreptitiously shot image).

The sign points to a wall. There's no pay kiosk on either side of the wall.

This could be blamed on a number of things, but for the sake of this post I'm going to pin it on a lack of user scenarios when the store was planning the pay kiosks. If, when someone in Sears corporate offices was thinking about or planning the kiosks, the context of shoppers making purchases came up, hopefully they would have realized that finding where to pay is just one part of a flow that ends with paying – that paying is a part of a larger scenario.

A few years ago, we worked with the marketing team at Sloan Executive Education. They run programs that are attended by professionals from all over the world. Aware that there was a flow of information, and that it needed to be consistent to ensure that expectations were met, we mapped out scenarios related to how potential participants found out about the programs, registered, made travel plans and arrived at the program. After listing all the recipient types and situations, we could evaluate the communications and see where information needed to be changed, added or made more consistent.

There are hybrid online/offline situations that call for scenarios as well. Hospitals can have complex and inconsistent technical setups that send healthcare workers back and forth between paper and electronic files. Working with a client who provides software to streamline hospital discharge, we needed to design a fax form that would literally connect paper and digital correspondence. Care facilities received faxes from hospitals to let them know there was a potential patient for them. Included in the fax was a unique code that, when entered on a website, would provide the patient details and acceptance information. We used scenarios that captured the full flow of contact – online and offline. Because we looked beyond the web interactions we were able to design a complete system that worked, not just a form or site that only addressed part of the situation.

Guest post on designing web-based communities for professionals

2010-03-19T06:32:00.000-07:00

We are pleased to contribute a post about design to Leader Networks' blog, Building Online Communities for Business. We've worked with Vanessa on a few projects, and it is always a pleasure. Vanessa's interest in and knowledge of communities of practice pre-dates the web. She's translated her expertise on the topic from the offline world to the online world, well, expertly.

Our LN post is geared towards an executive audience and is based on what we've learned from several projects: a partner site for MIT's Center for Transportation and Logistics, an invitation-only community for executives in the wireless industry, password-protected sites for business managers and technical clients of ATG software, and an internal community for ATG employees all over the world.

Check it out here: http://blog.leadernetworks.com/2010/03/designing-web-based-communities-for.html

Higher education: the destination site is not dead

2009-11-17T08:10:00.000-08:00

The pace and rate of technological change is dizzying. We are seeing and hearing many organizations become disoriented. In higher education as with any organization, when there are funds there is a tendency to want the latest and coolest. The possibilities available - cheap and fast streaming video, presentation design "skins" that change on the fly, the ability to aggregate and display content from a wide variety of sources - are tempting.

Critical thinking must be present in the higher education site redesign process. Like the dessert table at a great buffet, it is easy to over do it, and forget about providing the nutrients your body (like your site visitors) need.

Bottom line - if you are a site for a department at a college or university, your site visitors need facts. They need to know what the department is. They need to know how they might engage with you and for what. They need to know who is in charge of what and who to contact for what. They need to know how your department or organization may be connected to others or the university as a whole. Prospective and current students and their parents get a huge amount of their information from the internet. They are relying on your institution or department's site for the details they need. There are many, many sites that provide inspiration on every topic imaginable. Chances are, if you have a current or potential student on your site, or even a donor, they have been to those sites and are already inspired. They are on your site to move forward and take action - to go beyond inspiration and act.

Organizations must ask themselves - are they in the media business? If not, how cool and inspiring is your cutting edge site going to be in a few months when the content needs updating? How impressive will it be when news feeds pull in content that isn't what your audience is looking for or have already seen somewhere else?

Higher education sites are destinations. Ideally, they do both - inspire the visitor by reassuring them that they are in the right place for their interests (video could really help here), and help them engage. This takes more facts than flash, more veggies than dessert, smelling salts and a heavy dose of restraint (also known as user research).

Challenging the convention of starting with content

2009-11-10T11:10:00.000-08:00

When we were recently designing a new site for ourselves, the effort started with content. We thought that once we had an idea about the content, we'd to do the design. We developed a rough draft of the things we wanted to say, worked with a great writer and came up with a final draft.

Visual designs were based on the content. After a few rounds, we liked the design. The problem was, we were no longer satisfied with the words. What was it about reading the words in the design that made us want to change them? Everything had looked good in Word. If we had been just the web design team and not also the client we would have probably been annoyed: "Don't they know what they want? It's about to launch!" We had fallen into a trap we had seen but not experienced, the inability to visualize something without seeing it complete.

We were reminded that it takes two to tango – content and design go hand in hand to communicate, and should be developed simultaneously (along with behaviors if designing an app) as much as possible to create a cohesive experience. We should have recognized it sooner and prescribed one of our own solutions – using schematic page diagrams (aka wireframes) from the beginning to define content and layout at a high level. Schematics show the types of content without showing actual writing, and the hierarchy of the layout without showing visual design. If we had done them, once the wireframes felt right we could have moved the writing and the visual design along simultaneously, which would have saved a lot of time.

Using card sorts with storytelling to get off to a great start

2009-03-22T18:33:00.000-07:00

Working with non-profits often means large teams with multiple stakeholders, each with a list of desired features and improvements that may have been in the works for years. The expectation level is high – funding has finally been approved, a target launch date planned and everyone knows just what they want – in fact, a site map has been developed. While each stakeholder is trying to address the perceived needs of their audience, when it all gets put together the results can be unprioritized and sprawling. The team may have been meeting for months and are looking for the designers to pick up the ball and run. However, committee-driven IA can be so democratic that it can miss providing the information that site visitors are looking for in the way they expect to find it. Our favorite path to a successful project with multiple stakeholders is holding card sort/participatory design sessions with storytelling as soon as possible.

Traditional card sort sessions involve gathering data from participants by having them sort terms into groups that make the most sense to them. These sessions are a valuable tool for creating navigation that makes sense to the people who will use the site. A large numbers of participants (>30) is needed to provide the data, and software to sort the responses is helpful. While traditional sorts are not difficult to do, we have found that having sessions with fewer participants (5-12) and mixing approaches provides input that covers several areas beyond defining appropriate navigation categories.

When sessions include prompting participants to tell stories about a specific time they used a site, perform a card sort, and use cards to position content and features on a page the way they'd like to see it the data is deep and rich. The results provide a clear picture of each person's mindset, and how that mindset affects how they think about content, categories and what they value. Patterns emerge that point to pretty clear user group needs. While it doesn't provide deep statistical data, it does provide rich scenarios of use and an understanding of needs and values that is just what we need to get buy in from stakeholders to prioritize the feature list and focus the IA on the top issues and most common situations.

When moving fast slows you down or, one more reason why prototypes rule

2009-03-11T10:54:00.000-07:00

Sometimes, we go right from creating schematic, or wireframe sketches on paper to visual design. There are often several rounds of sketches before they are approved and visual design begins in earnest. On complex applications, this is a mistake. Paper-based wireframes, even several rounds of them, do not give the team a chance to test drive the application. This leads to lots of "oh, yeah" changes when the team sees a working build with "final" graphics in place, even if the visual design and the wireframing have gone through several rounds.

"Everything is changeable on the web - what's the problem?" Creating visual design for complex web applications involves layers, lots and lots of graphic layers per page template. For each button, for example, there are several states. For each state, there are vector (working, editable) layers, and final, "raster" layers for the same button. Four layers, easy, per button. Finding the right layer and changing it to match all the other buttons, even in well-organized files is time consuming and error-prone.

Add all the files from all the rounds of design, the passage of time from final graphics to working staged site, and the problem grows. Changes to complex web applications once the graphics are in place are time-consuming and lead to messy, hard to manage files. Often the change needs to be made right away, and a designer (no one I know ;) might edit a flat .jpg rather than the original layered file. While this seems harmless at the time and gets the problem solved quickly, what happens when the same item or similar item needs the change again - another "oh, yeah"? More time to find, edit, make the same as all the others, for a word change that everyone thought could be changed easily later.

Maintainability and integrity of a UI design suffers when the design is picked apart for the sake of wording and functionality edits once complete. Web application visual design is often about subtle juxtapositions. When features are unexpectedly added or changed, the details of the design can fall apart, reducing the overall impact and effectiveness of the design that was labored over and approved.

What to do? Prototype. We know prototyping helps interaction design and feature definition. We know prototypes (limited functionality, no design) are easy and helpful to test. The news is that it helps visual design, too. When prototypes are vetted, "oh yeah" changes are dramatically fewer, allowing the design to be its best.

The Web 2.0 look and feel "gotcha"

2009-03-11T07:51:00.000-07:00

The Web 2.0 look and feel is still hot. People really respond to the super-glossy buttons, organic background shapes, colorful gradations and graphic type. At the same time, web applications are rapidly improving. We've seen some really great ones lately, MailChimp, Picnik and Kontain come to mind. While there are great examples of slick looking and acting, fully functional applications, these applications are hard to do. Web applications are functional by nature. Graphics-intensive Web 2.0 look and feel is not. For every graphic text header, there is a tired design developer who has to change the graphics any time there is a word change. In short, maintaining heavily graphic sites is (still) a lot of work. The more functional an application, the more things change, the more graphics to create, manage, maintain.

Before committing to slick buttons, styled type and rounded everything, consider how often elements are likely to change. Consider the work flow (who will do what) when things do change. Consider putting the graphics in areas behind system text to give a rich look without the maintenance hassles, or letting a highly styled logo carry the slick feel. Consider Google, which is what everyone wanted to look like in the last web design fad. Consider what visual elements are really important to communicating your brand. Got great developers, organized PSD file templates, time and manpower to make changes regularly? The sky's the limit.

Try again ... this time in English.

2009-03-17T15:52:00.000-07:00

One of the most frequent problems we see on websites is jargon-heavy text. There are many reasons why this happens: maybe the writing team is so used to serving an internal audience they don't realize that others can't understand their content; or maybe the website serves an industry that thrives on buzzwords, such as consulting. Sometimes it just happens by accident or because no one has time to really review the text before it gets posted. But no matter the cause, the result is almost always a site that feels insular, unfriendly, and worst of all, crammed with content that doesn't resonate with the audience.

One of the worst offenders on many sites is the legalese on Terms of Use pages. Hardly anyone other than lawyers actually reads these closely; they're just long, impenetrable documents we all have to pretend we've read before we can check off a box and complete a registration form.

But this week, the Consumerist singled out Aviary, a site providing online graphics tools, for their radical and simple approach to their Terms of Use page: they provided an English translation paralleling the legalese. Using concise and friendly language, Aviary spells out everything you'd want to know about their Terms of Use, from who owns the graphics you create on the site, to the different payment plans they offer, to the licensing agreements for site content. Aviary's approach transforms an unreadable page into one that anyone can understand, a goal consistent with their mission to "make creation accessible to artists of all genres."

We hope more companies follow Aviary's lead and make their content clear and easy to read, which is a more successful way to reach their audience than "buzzword compliance."