seen + learned

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

Posted: Thursday, July 22, 2010 | Posted by Tania Schlatter | 0 comments

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.

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

Posted: | Posted by Tania Schlatter | 0 comments

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.

Making "Support" helpful - some tips for Twitter

Posted: Tuesday, July 6, 2010 | Posted by Debby Levinson | Labels: , 0 comments

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.