Straight From the Horse’s Mouth with Derek Featherstone

by:   |  Posted on

iTunes     Download     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif Christina Wodtke traveled with microphone to the IA Summit in Las Vegas this year and sat down with some of the most interesting and accomplished information archictects and designers in all the land. Bill Wetherell recorded those five conversations, and now B&A is proud to bring them to you. Thanks to AOL for sponsoring these podcasts.

Christina talks with web accessibility and design expert Derek Featherstone about considering accessibility as a foundational part of the design process. By doing so, he argues, the software we build will have better structure and be inherently more useful for everyone who uses it.

This interview is a must listen if you want to learn about this emergent part of our practice that started as a grassroots movement in developer communities.

We discuss…

*What do IA and Accessbility have in common?*
Derek looks at the bigger picture when it comes to accessibility, believing that focusing on accessibility by itself will cause the web design to fall short in other important areas.

*Fashionably late?*
Derek goes on to outline the problems of brining accessibility issues to the table late in the design process, including impact on project scope. As Derek points out, better to measure not once, but three of four times before cutting…metaphorically speaking.

*Easy does it!*
Derek talks about specific examples of issues that have arisen when sites for the Canadian Federal Government have been found to be inaccessible and the consequences that follow.

*Heart and Soul*
Derek talks about the value in this work is knowing simply that he’s helping people with disabilities share in the same experiences as everyone else. “I don’t think I could even make an inaccessible web site, now!”

*Structure is at the Core*
He describes how structure (following HTML web standards) allows assistive devices to know what the page is communicating.

*Interaction Design and Accessibility*
Derek suggests trying to think about accessibility from an Interactive perspective. Using things like flow, and rhythm to convey meaning in something we read for those who can’t see.

*Flash in the pan?*
Derek thinks there are great Flash sites and use of the product. In fact Flash has a wealth of accessibility features at the developer’s disposal. The message is just not getting out there fast enough.

Straight From the Horses Mouth with Derek Featherstone.

Automated Voice: This broadcast is brought to you by AOL, now hiring designers in Silicon Valley, New York City and the Washington, D.C. area. Help us set the standard for what happens next on the web.

Send your resume to today.

[Theme music]

Female Voice: Boxes and Arrows is always looking for new thinking from the brightest minds and user experience design. At the IA Summit, we sat down with Derek Featherstone from Further Ahead.

Christina Wodtke: I’m Christina Wodtke of Boxes and Arrows and I’m sitting here talking with Derek Featherstone. I don’t even know the name of your company.

Derek Featherstone: My Company is called Further Ahead.

Christina: Further Ahead, I like that very much. So, Derek you are here talking to folks about accessibility and from what I hear, your workshop was fairly well-attended, pretty crowded in there. So tell me, what is it about IA and accessibility? I wouldn’t have guessed they have a lot to do with each other.

Derek: I think, for me, the way I see it is that they are both related because they’re both part of overall user experience.

A lot of people look at accessibility as this little thing that’s on its own but if you do accessibility on its own and treat it as its own component, it becomes like a second class citizen and so it’s not integrated into everything else that we’re doing.

And when you treat it as something that’s just kind of like the checklist training – that’s what everybody thinks of when they think accessibility is this checklist of things that we need to do.

It really becomes something that is removed from the overall design process and the build process, and understanding it as part of user experience on how people, actually, use the web.

Christina: What are some of the bad consequences of having it outside of the design process?

Derek: Well, I think the biggest problem that I’ve seen is that it just gets addressed too late in the process.

So I’ll have clients sometimes come to me two weeks before they are ready to launch a site and they know it needs to be accessible and then I’ll go through and I’ll do an assessment of it, will do user testing with it and will go back and say: “There’s a lot of things that need to be fixed, let’s make this happen.” It’s like they can’t go live or it goes live with a lot of accessibility issues in it.

So that’s, sort of, the most significant problem – is that it gets dealt with too late and then it cost money because you have to go back and retrofit.

Retrofitting a site is never fun and it can be a lengthy process especially depending on how far along you are and how complicated your framework is, what you’re doing on the back end in terms of code.

You might not be able to change things as easily as if you’d dealt with it up front and how accessibility is taken into account at the prototype stage.

So that’s the number one issue, I think – is that it just — it becomes an afterthought and then it’s seen as this button that you just end up with an inaccessible product because of it.

Christina: So it’s an old adage of measured twice and cut once?

Derek: Or measured three or four time and cut once.

Christina: OK. So what happens to those sites where accessibility problems go live? What happens when you aren’t as careful as you should be?

Derek: I mean, depending on who you are, you are kind of hope and pray that you don’t run into any issues where people — you know in Canada, for example, we have sites that may have accessibility problems that are federal government sites and people will launch actions.

They’ll bring that to, say, Canadian Human Rights Commission and they will say: “There’s this service that’s offered online that I can’t access because it’s fundamentally inaccessible. There is all these issues with it.”

So that works its way up the food chain through a process to get resolved. So that’s certainly one of the dangers in Canada.

You know, here in the states, it’s a little bit different although very similar as the Human Rights Commission, but ultimately Section 508 here in the states is there to guarantee or at least provide for a minimum of accessibility.

I’m not sure if people launch complaints with the governments or if it’s more dealt within a civil manner as we see all kinds of suits these days against companies in Texas and the National Federation of Blind launching their suit against Target.

I think the one in Texas was Oracle – all this legislation exists and if you’re not accessible then you’re, kind of, get caught with your past though.

Christina: So lawsuits and government action is at stake. Is there a carrot as well to encourage people to think about accessibility?

I’ve heard some people talk about, like, good code and good accessibility, meaning good search engine results; can you give us some advantages?

Derek: Yeah, I mean, that certainly is one of the advantages. There is a danger though in that being the motivation for it.

I think that biggest carrot is that we are doing this to help people with disabilities use the web. I see the web as, and I think a lot of people see the web, as great tool to level the playing field.

Having the ability to be somebody that’s, say, blind or is, say, confined to a wheelchair, they have the ability to shop online just like anybody else can.

It is an attempt or hopefully a mechanism to get that level of playing field and unfortunately that’s not reality. So the biggest carrot for me is knowing that people with disabilities can actually use the web the way it was intended to be used.

And I know that one of the things that I’ve always done that’s worked really well is for people that don’t necessarily know about accessibility or don’t know some of the advantages of it, just doing user testing with them or having them observe user testing some of the frustrations of using even their own websites.

Getting business owners and people that are driving groups – the owners of the websites to see it for themselves and to hear it for themselves really makes a big difference.

So that’s the carrot that I like to use although there are definitely benefits from a search engine optimization perspective. The foundation of accessibility, really, is that structured semantic underlying data and that’s the same for search engine optimization, so the two of those fit really nicely together.

You know, there are other things too like lightweight pages make it easier to download, things like that. So those are all these extra side benefits that may help people that want to browse on a mobile device. But I don’t see those as being, certainly — those might be like 10 karat and people with disabilities are like a 24 karat.

Christina: 24-karat carrot.

Derek: Yeah, exactly.

Christina: I like that. So well, luckily, you have all those carrots because I have noticed the business are not always altruistic as we might want them to be.

Derek: Yeah, it’s true. I mean, it is something where — I’m fortunate in that all the clients that I have and that I worked with, I never really had anybody that I’ve had to sell it to them and used those other carrots and especially when I’m developing sites and building sites.

This is just the way we do it now. I don’t think I could even make an inaccessible website. I mean, this is the way that we build sites now and that’s just how it is. There’s nothing to, really, sell in a lot of ways.

Christina: So you mentioned that you have more work than you can, actually, possibly do right now and that you’ve been doing this for awhile, do you think that there’s an increased awareness of the value of accessibility? Do you think more people are worried about it or caring about it in the past?

Derek: Yeah, I think some of the visibility or some of these lawsuits is having an impact. I think there is more awareness of it in general and I think a lot of people – there’s, kind of, a web standards’ movement among developers that just keeps growing.

So there’s a group of people that are just out there, that are just doing this because it’s the right way to do things.

So I think that it’s kind of a — is this grassroots movement that is helping to spread that vision of accessibility into organizations all over the place. So I think people are definitely more aware of it these days.

Christina: Earlier you mentioned the lightweight pages, are there some other core precepts of accessibility that you could share?

Derek: I think, well, I mean, the absolute based one is structure – having that structure that enables assistive devices to understand a little bit more about what the page actually is.

Christina: What do you mean by structure?

Derek: Just structuring your page so that you have —

Christina: The HTML? The —

Derek: Yeah. Yes, so using the right HTML for the job. So having headings, lists, block quotes – using the age-old sins of HTML was we to indent our texts so we’re going to wrap it all in a block quote or maybe two or three block quotes to bring both the margins. We just don’t do that anymore because block quote actually has meaning and there is a certain semantic to it.

A screen reader will announce that a block quote is a quote.

So if we have three-nested block quotes together to indent something on a page, it just doesn’t make any sense and that’s extra noise for a screen reader.

So, I mean, that’s just one example, we want to make sure that we’re using the tools that even though HTML is an overly semantic latent rich language, we want to use what we do have to its best.

So using lists properly on other lists and ordered lists, using tables properly, using headings, block quotes, all these different elements that we have for the right reasons.

Christina: So are there other ways to make pages a little more accessible?

Derek: Yeah, I think one of the things that I’ve been pushing a lot of people to do or to at least consider is to think of it from an interaction perspective.

One of them is — one of the ways to do that is looking at the visual languages that we create with our designs. We use color and we use actinography and we use things like rhythm and flow and similarity and size, similarity and color.

We use all that visual display to convey meaning to people that can see.

So how can we take that and translate that into something that is useful for our screen readers? So if we’re talking about things being the same size and having the same, sort of, weight then we should do that same thing in the underlying HTML.

So just taking that extra step to think about what you are trying to visually communicate and thinking about ways to communicate that in other ways to people that may not be able to see.

Another example is, you know, we might have sections of a page where we’ll have primary navigation across the top and secondary navigation down the side. We can visually see that based on the position on the page, these lengths are different from those links.

So there are other ways to try and convey that.

You might include, say, before your secondary navigation, you might include a hidden heading that says: “In the section” so that you can distinguish from the primary navigation links from the secondary just so that it makes it a little bit more clear as to what all these different components are.

So that taking that visual to translating into something that’s meaningful in some other way to somebody that’s consuming a page through auditory means.

Christina: So with the penetration of broadband to a much wider audience, we are seeing a lot more use of Flash and Ajax and streaming video, what, sort of, opportunities or challenges are you seeing these days?

Derek: It’s interesting because there’s a lot of belief that, well, because we now have this broadband penetration we can do whatever we want.

One of the main issues that I’ve seen with that is the use of Flash – I think that Flash is great, I think it’s got some really — some great uses on the web, but one of the things that happens is Flash developers don’t necessarily know all the accessibility features that are built in the Flash.

It’s not really well know, but Flash has, in some ways, better accessibility support than technologies like using things like Ajax.

Christina: Wow.

Derek: And that’s been there for some time.

I mean, Macromedia and now Adobe with Flash. They have been putting a lot of time and effort into making that accessible and that’s — they’ve got — right now, at this point, they’ve got better programmatic control over talking to, say, screen readers and through that accessibility architecture that’s built into your operating systems.

There is better support there for things that — for reaching that applications than there are in Ajax right now.

So that’s one of the big things – is with the proliferation of Flash, people don’t even necessarily know that it can be made accessible. The old story was, well, it’s Flash, so it can’t be accessible, but that’s not true. There’s a lot of things in Flash that can be made accessible and the principles are pretty similar to what we have in HTML.

You need to enable keyboard access, so all your buttons that you have in a Flash will lead to, say, save it with your online video, like things that YouTube or Google video or wherever.

All your buttons that you used to control, they need to have the ability to take the keyboard focused, so that you can tab through them.

So you need to label them so that they just don’t get announced as “button” by a screen reader because button, if you have five things that are all announced as “button”, it’s not clear what it is.

Christina: “Button, button, who’s got the button?”

Derek: Exactly. Exactly. So that’s a big challenge right – is encouraging other people. There are some really brilliant people working on Flash accessibility but it’s just not proliferating. We need to continue to get that word out that you can make Flash accessible.

Christina: Well, you know, Ajax is the flavor of the week and flick or flip completely out from Flash to Ajax and we’re seeing a lot of other new Web 2.0 items in Ajax.

What should people be thinking about is as you sit down to knock out the next most amazing project ever?

Derek: That’s a good question. I mean, in terms of accessibility – I know I have said this a lot now, but the underlying structure is almost everything. That gives you your framework.

So having good, solid HTML which most people that are building new applications are these days, really, what they need to do to take it to that next level is think of the interaction and think of that Ajax component as that final enhancement rather than the first enhancement.

A lot of people think about it – they start creating a new application and the very first thing they do is say: “OK, this is going to be Ajax-driven.” If we can avoid people thinking that way, let’s think of the core structure first, what are we actually trying to do in terms of our interaction?

Then how do we enhance what we’ve already got with Ajax?

Christina: Now, that does sound like information architecture and interaction design to me very much.

Derek: Exactly and the biggest thing that people don’t ask is should we even be using Ajax for this in the first place? And that question just doesn’t get asked enough. There are lots of examples out there where there’s really —

Christina: You mean [indecipherable] names?

Derek: No, I’m not even thinking of any applications in particular but there are situations where the assumption has been we need Ajax to do this but all these things that are happening in this Web 2.0-sphere that are all around tagging at social interaction and social networking, we don’t need Ajax for any of that.

Those ideas are really just concepts; it’s nothing to do with the technology.

We can use Ajax to make those concepts come to fruition in a much more usable manner and in some ways it’s almost more accessible to use some Ajax-type techniques because the fact that the page doesn’t refresh means we don’t lose all that context and have to wait for that page to reload.

So it’s quite possible that using Ajax to expand the nodes of a tree in a file view, for example, might actually be more accessible because it’s easier to maintain contexts; people don’t have to go through that refresh.

So there’s a lot of interesting things to think about that. We’ve only really just started exploring.

Christina: OK. So let’s say, you know, I am that little company and I will say I’ve built it, I didn’t think about accessibility, what should I be looking for just to see if I’m going to be in deep trouble with the law? Is there any quick way I can go through and see if I’ve got big trouble or little trouble?

Derek: I mean there are online checkers that can do a quick and dirty analysis for you.

The biggest problem with it right now is that a lot of accessibility even though there is a checklist to reliably and mechanically checks for those things in automated way, you can maybe hit 25% to 30% of the issues. So you do need to do a bit of a manual review.

One of the things that you can do though, and I do this all the time, is go out to the local college or university and get people from the center for students with disabilities and just get them to — you know, they’ll be more than happy, usually to volunteer to test things out for you.

Christina: After users?

Derek: Yeah, I know it’s crazy, isn’t it? Unbelievable. I mean, who would have thought?

Christina: You’re a radical thinker.

Derek: I know. I know it’s crazy. It’s crazy.

Christina: Well, this is fantastic. Thank you so much, Derek, any last words to the folks thinking about accessibility out there?

Derek: You know, the main thing is just keep thinking about it because that’s what we need – is we need more people thinking about it all the time.

Christina: Make good code and think about your users out there.

Derek: Exactly.

Christina: Sounds good no matter what you’re working in.

Derek: Absolutely.

Christina: Thanks, Derek.

Derek: Thank you.

[Theme music]

Bring Your Personas to Life!

by:   |  Posted on

“So you’ve got your persona set all neatly defined and documented. Now what? How can you ensure the persona isn’t ‘just another deliverable?’”

Most user-centered design (UCD) companies create personas (profiles of representative users) to guide their designs. To do UCD, you need to get the “U” in focus right from the start. So you’ve got your persona set all neatly defined and documented. Now what? How can you ensure the persona isn’t “just another deliverable?” Continue reading Bring Your Personas to Life!

Uncovering Users In Your Own Organization

by:   |  Posted on
“It’s still research, but from an internal perspective. There is a wealth of information at your fingertips in your own office, and surprisingly, some of it is usability-related.”This article is the first of a two-part series that recommends internal resources that you can assess. In Part One, we examine customer databases. In Part Two of the series, we will consider other internal resources, such as product managers, call support centers, field consultants, and corporate surveys.

Buying new clothes and looking at current fashions is usually much more interesting and exciting than digging through one’s closet or laundry hamper. However, there is a lot one can learn by stopping and taking a minute to examine one’s own clothes. Such a review can tell you history (past fashions), document what you’ve been doing (attending a ball game, as evidenced by that ketchup stain), and indicate what you need (oh, yeah, I need a shirt to go with those pants). As user experience professionals it is crucial to your success that you learn who your users are, understand their environments and business needs, determine current user interface (UI) problems with the products, and review design solutions with users.

Like most of you, I can’t wait to get into the field to observe users working with my products. Yet, I’m going to pull on the reins, and do a 180-degree turn. Don’t worry – it’s still research, but from an internal perspective. There is a wealth of information at your fingertips in your own office, and surprisingly, some of it is usability-related. You can optimize your internal resources by understanding where and how you can find UI information about your users within your own company. To provide context and practical guidelines, this article presents examples of how to mine internal resources at a large enterprise software company.

Beginning with the end in mind
Successful research initiatives begin by first considering the research questions that need to be answered, then by selecting sources and methods to obtain those answers. Many user experience (UE) questions can be answered by examining internal resources. These questions may include:

  • Who are the product users? What types of industries do they represent?
    Although these might sound like marketing questions, they are important for UE professionals to know as well. Defining the user base is key for research purposes, as well as for understanding the usability patterns emerging in different markets. One would expect that a hospital, for example, might use purchasing software differently than a manufacturing company.

  • Are usability issues already being documented within your organization?
    Before running numerous usability studies and visiting customer sites, first find out what customers are already reporting. These reports can be a low-cost way to collect and summarize feedback and can direct your future research initiatives.

  • Where is the UI becoming an issue in your organization’s business? What are the usability hotspots?
    You can ask questions to determine whether the UI is affecting:

    • Revenue-generating sources: new sales, upgrades, and competitive pressures
    • Customer relations: implementation, training, documentation, and help desk calls

    Assessing internal documentation can help the UE team react to some of these problems and make the appropriate changes before problems escalate.

Internal resources
Most companies–small, medium, and large–maintain their product, sales, and customer knowledge within some sort of information documentation system. This knowledge organization can range from Excel spreadsheets to multi-database knowledge management software solutions such as Lotus Notes (Zorn & Taylor, 2004). Every company categorizes and prioritizes information differently. Likewise, not all companies have the same resources written about in this article and many have additional sources not addressed here. At a minimum, this diversity provides directions for exploration.

PeopleSoft’s UE team has found it valuable to look at the following sources:

  • Customer Database
    An application that supports all customer-facing operations. This application feeds into a database that contains all customer information, including customer contacts, business details, market details, products implemented, and licenses sold.

  • Support Call Center
    Most companies with a customer call center have a tracking system to log the issues reported by customers. Many log issues into categories, such as “usability.”

  • Consultancy and Implementation Services
    Consultants have day-to-day experience with product implementation and customization. They document customizations made to the UI based on customer needs, such as accommodating changes to infrastructure or business processes.

  • Product Managers
    These individuals have ongoing dialogues with customers that influence the future direction of the product. Product Managers can alert UE teams to design issues, such as a major redesign needed due to newly added functionality.

  • Company Survey Data
    Most mid- to large-scale companies evaluate their customers’ satisfaction with their products. Usability may be one of the dimensions surveyed.

Examining and synthesizing information from your own corporate resources will allow you to have a deeper understanding of customers and users prior to conducting field and usability research, incorporate usability findings into the product release cycle phases, and leverage internal relationships for future research and design reviews.

When to assess your internal resources?
Assessing internal resources is a continuous task. Information is constantly being updated, in many cases daily. Reevaluation of data may occur quarterly, yearly, and/or at salient times during the product release schedule, such as the product planning phase.

Another key time to investigate internal resources is when you start a new job. This is a great time to understand the knowledge management tools and information collected within your organization. Identifying your key contacts and information sources as early as possible helps you be more productive, efficient, and better at decision-making. Questions you may ask yourself include: who does what, when, and how? Who has liaisons with the customers? Which interest groups have an impact on the product designs? How is customer feedback typically handled?

Findings first! What types of usability results can you expect to find by doing internal research? Table 1 below provides a description of each resource, denotes the format, and identifies key usability issues that can be uncovered.

Data Format
Types of UI Issues
Customer Database
Database with customer contact info, company stats,
product and license details, etc.
Call Support Center
Customers call product support staff to report specific
application-related problems.

Labeling issues.

Error messages incorrect or ambiguous.

Need to change displayed defaults.

Interaction difficulties.

Not able to complete task due to process.

Product Managers
Customer-facing liaisons who provide guidance, feedback,
and strategic direction into the product.
Interpersonal communication

Customer-specific feedback.

Customer hotspots.

Feature- and functionality-specific issues.

Field Consultants
Consultants determine business requirements and set
up and implement products at customer location. Customizations are made
on the basis of needs.
Interpersonal communication

Inconsistency within products, across modules.

Mismatch of terminology with real world terms.

Documentation not enough, need more clarification.

Technical response times too slow, batch processes run at inappropriate times.

Interaction design not portrayed as customer expects or needs.

Corporate Surveys Customers are asked to fill out surveys regarding products, satisfaction,
and company loyalty.

Overall sense of usability satisfaction with products. Generally, high-level information.

Table 1: Usability issues uncovered by internal resources

Mining customer data
The role of market research in the user-centered design (UCD) process (Norman & Draper, 1980; Norman, 1988) is not explicit. Usability professionals need to be responsible for the data they collect and need to understand how their customer base is distributed to ensure that key industry customer types will be properly represented in their future research. Analyzing your customer databases, therefore, should be the first step-before running usability studies, before field research, and before design-to truly understand who your current customers are. Do not rely solely on others for this information, as most departments have their own competing priorities, but verify the information for your team.

“Once you understand the customer database, you can identify which markets to recruit users for research.”Getting started
The process of accessing customer databases may take more time than you initially expect. The raw data might be classified as company-sensitive information and, therefore, may have usage restrictions. Usability teams are not always given access to customer databases and you may have to work with the marketing or sales departments to gain data access. Furthermore, you may have to take classes to learn how to use the data application, how to run queries (commands for pulling the data you want), and understand how the data is entered into the system (how columns and rows are defined).

As you gain access to the system, you will want to cultivate relationships with key people who work with the datasets. We recommend identifying:

  • The initial gatekeeper who can help you gain entry to the system. In our case, we needed buy-in from an expert user of the system to request that we be given entry-level access.
  • A database expert who understands the source and classification of the data. We found that differing database queries led to result sets that had to be reconciled. (Either the queries were not matching up or the polled datasets were different.) Experts can answer questions about the data structure, queries, and problems you may run into while using the system.
  • Key product experts who can verify the synthesized data that you produce. Once you identify the percentages of key industries per product, you need product managers to verify that the numbers actually reflect their products.

In the software domain, customer data can be classified by a number of dimensions. If our research is to inform our UCD initiatives, it is important to consider customers who currently use our software and to identify categories from which we can easily recruit.

To begin, from your larger database create a sample of customers for which you are interested in gathering more detailed facts. For example, our UE team initially ran a query that selected customers based on: 1) product type (e.g., inventory customers); 2) customer status (e.g. actual license holder vs. prospective customer) ; and 3) status of product usage: must have implemented the product and be a current user. How your data is classified will influence how you can filter it.

Caption: Key industries for Product XYZ.

Once the sample is defined, you can run crosstabs by key variables you would like to learn more about. In our UE group, we really wanted to know which industries were purchasing certain products. We created pie charts and lists of key customers to reflect the core industries for each product type (e.g., purchasing software, inventory software). This segmentation was important for three key reasons. First, we wanted to be able to identify various user roles within an industry. To do this, we needed to know the core industries for any given product. In our case, the core industries for Product XYZ are: healthcare (25 percent), education (15 percent), utilities (20 percent), and financial services (40 percent). Second, the industries can define the type of user for whom we are developing our software. For example, is the user base primarily expert or more self-service?

Having a picture of those for whom we are designing at an industry level helps us then select users who are more representative of our user group for additional research. This leads us to the third reason: we can use those top industries as the first places we recruit users to create user profiles and then abstracted personas. Our long-term UCD goals were to create personas for our design and development teams. Understanding the industries where our users work was the first step of this research agenda.

One side note: future sales projections or targeted markets should also be considered when interviewing individuals for user profiles. Projected information cannot be collected from the customer database but needs to be gathered from talking with product managers, sales, and marketing. This information will indicate new user groups to consider and possible changes to the distribution of potential and current users.

Advantages, disadvantages, and considerations of the data
Now what? This customer demographic and sales information alone will not increase the usability of your product. It is, however, a step toward understanding your users. This deeper understanding will inform both the recruiting for usability testing and the process of designing the product itself.

There are two challenges that you should be aware of during these database analyses:

  • Customer versus User dilemma
    From a usability standpoint, we design for the user (the person using the application on a regular basis), but the data collected is based on the customer (the management or business analysts who make application selections and purchases). Does this fact then make the information less useful? No, it is still useful to know the industries that we are selling to. However, we recommend ensuring that subsequent research focuses on the user and that you understand their use of and perspective on the software.
  • Data validity
    Salespeople often enter customer information. As with any human-managed process, there is bound to be some error involved. This can be through mis-keying of data, not collecting and reporting on all key questions/fields, or through mis-categorizing or misunderstanding what the customer was saying. In addition to how data is entered, there is also the concern of how current the data is. Realize that there is some percentage of outdated information in these databases. Always validate data with the product manager and the person who entered the data.

After identifying the core industries your products serve, you will want to understand the types of user roles within each main industry, which most likely will require additional research, such as interviews with customers from those industries. From there, you’ll want to make sure that you recruit an appropriate sampling of users from the key industries and identify user roles to truly understand how each user group and/or industry is using your application.

The User Centered Design process (Norman & Draper, 1980) is well-accepted, endorsed, and integrated into many software corporations. Users provide context, feedback, and validation to designs using a spectrum of methodologies ranging from contextual inquiries (Holtzblatt & Beyer, 1993) to usability benchmark studies. To do this type of research and design can take considerable time, resources, and financial investment. One of the most overlooked areas to inform user interface considerations is within our own companies. Corporate resources are seriously undervalued and underused, but are at our fingertips. As a first step, we should determine where usability issues are already being documented within our organizations and where they could be used to inform our design decisions.

This article is the first of a two-part series that recommends five internal resources that should be assessed. In this article, I examined customer databases. In part 2 of this series, I will consider the following internal resources: product managers, call support centers, field consultants, and corporate surveys.

Mining customer databases is an essential first step to really identifying who user experience professionals are designing for. The information is at a high level, but extremely valuable when determining who to recruit and where to focus additional research efforts. Furthermore, this information is a level of data most other stakeholders in the company (such as marketing, sales, and strategy) can understand. It also helps in starting dialogues with these other working teams. UCD teams should take responsibility for performing, or at a minimum overseeing these analyses, to ensure accurate results. In sum, begin with the end in mind by optimizing your own internal resources.

For More Information

  • English, J., & Rampoldi-Hnilo, L. Remote contextual inquiry: A technique to improve enterprise software, 2004.
  • Holtzblatt, K. & Beyer, H. (1993). Making customer-centered design work for teams. Communications of the ACM, 36, 93-103.
  • Norman, D. A., & Draper, S. W. (Eds.). User centered system design: New perspectives on human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum Associates, 1986.
  • Spradley, J.P. The ethnographic interview. New York, NY: Holt, Rinehart and Winston, 1979.
  • Wood, L. E. Semi-structured interviewing for user centered design. Interactions, March + April 1997, 48 – 61.
  • Zorn, T., & Taylor. Knowledge management and/as organizational communication. In D Rourish & O. Hargie, Ed., Key Issues in Organizational Communication. Routledge, in press, 2004.

Lynn Rampoldi-Hnilo is a Usability Engineer/Researcher at PeopleSoft. She initiates and leads the user experience research efforts for the Supply Chain Management product line. Prior to PeopleSoft, she worked as a market researcher at Cheskin on media (e.g. Internet effects and transmedia trends), product development of communication technologies, and usability and interface design studies. Lynn completed her Ph.D. at Michigan State University with an emphasis on technology and cognition. She has taught communication theories and social science methodologies at Stanford, Michigan State University, and St. Mary’s College.

John Stickley (Illustrator) is an Information Designer with over 10 years experience translating complex systems, concepts, and experiences into accessible visual solutions. His site Visual Vocabulary shows a complete overview of his work.

Making Personas More Powerful: Details to Drive Strategic and Tactical Design

by:   |  Posted on

“Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs.”

How can something that feels so right be so wrong? Personas ought to be one of the defining techniques in user-focused design. Lots of professionals create them, yet too often the personas end up being too vague to guide a product’s focus. They often lack the detail to be useful in guiding low-level design trade-offs. And, as typically done, personas have been too narrowly focused. They often aren’t helpful in identifying the information a user needs or creates. Nor do they have much to say about the sensory and emotional aspects of user experience–the sorts of factors that cause consumers to lust after products like Apple’s iPod.

As a result, personas have unfortunately become more of a check-off item than a useful tool, and many personas get put on the shelf once they are written. So how did we get here? Continue reading Making Personas More Powerful: Details to Drive Strategic and Tactical Design

Extending a Technique: Group Personas

by:   |  Posted on

Spock: “The needs of the many outweigh the needs of the few.”

Kirk: “Or the one.”

–Star Trek II: Wrath of Khan

I recently had the pleasure of teaching a workshop on applying user-centered design methods to personal technology design in a European amusement park.

The workshop started out typically. We interviewed company management, mapped out the goals of the company, the context in which the project was being done and collected information about how people currently behaved in the park. We then identified several classes of users, created personas for them, and started creating scenarios using these personas.

Initially, the workshop progressed about as it would if we were going to be designing a piece of desktop software or a website, but the minute we started developing personas and scenarios, the unique nature of the park started to become clear. Continue reading Extending a Technique: Group Personas