First draft of a chapter for the second edition… love to get some help as I warm up.
Background: we’re trying to tighten up the book so it reads more quickly and can be accessible to more people. In doing so, we tried to collapse two chapters into one. I’m wondering if the section “those people” should just be axed. Yes, it’s useful information but is it really relevant to information architecture in particular and is it really necessary in this era in which there are so many good books on user research?
Please forgive dreadful formating madness… I exported pretty directly from Word, and we all know how well that works. But I’d rather spend time writing than formatting.
Chapter 2: Balancing acts: users, technology and business
In which we discover that businesses like to make money
The role of the information architect has often been compared to that of a film director. Like films, creating websites is often a collaborative act, as much about coordination as design. Secondly information architecture sits firmly in the transition from abstract strategic thinking and concrete implementation thinking. Like a film director, the IA must take a concept and figure out what that really means–where will people go, how will they interact, what is their motivation?
The IA (or whoever is playing that part) must understand the various forces at play in the creation of a website. Misjudging the business goals, or underestimating technical complexity or lacking empathy with the desired user base is dangerous to the success of the effort. While there are dozens of other forces at work in website creation form marketing to graphic design, especially in a large organization, these three in particular need to be balanced as a website is mapped out.
Defining your play-space
You have to know three things before you even open Visio (or whatever your favorite tool is).
- Who are you making this thing for?
- Why does your business need you to make it?
- What are your materials?
(d)Who- know your optimal user
You have to know who your end user is going to be. You can’t say that your audience is anyone on the web and hope to make something effective (unless you are Google, and they had to resort to black magic .) If you know who your target user is, you can effectively create a compelling website.
Be a rolling suitcase
In the beginning, only flight attendants had rolling suitcases. They had them because someone who understood their job had designed to a very specific set of needs. Flight attendants needed to dash from flight to flight. They had to stay fresh for the long flight’s exertions, so they didn’t want to tire out carrying a heavy bag. Many flight attendants were quite petite, so carrying a big bag could be tough. Yet they were changing flights so often, they really needed to carry on all their essentials-they never knew when their job would send them to Tokyo when their bags were already on their way to Paris.
Does this sound familiar? Ordinary people go through the same pains when they fly. We want to carry on our valuables, we need them to fit in the overhead compartment, we get tired carrying bags in the long lines to the ticket counter, or while dashing from Terminal C to Terminal F…. and our bags often seem to be determined to head for Paris when we are en route to Tokyo.
A designer met a very specific need extremely well, and ultimately he met the needs of flyers everywhere. It’s your job to do the same. Understand that core audience: who are they? What are their unique needs? Then meet those needs perfectly.
(d) Why–know your business
While information may want to be free, people like to get paid. Most businesses exist to make money. This is one of those “so obvious I keep forgetting it’s true” statements. You may find yourself in a meeting, arguing with business development or marketing and saying “No one wants to pay for that.” “No one wants to give their personal information.” “No one likes to fill out forms.” No one likes to pay for groceries, either but somehow we find ourselves doing it week in and week out.
Business analysts love to boil everything down to supply and demand; all business is driven by the fact that one person wants something and the other person has it. For example, the business has a piece of content, and the user wants it. Conversely, the user has personal information, the business wants it. Or perhaps wants the user to see advertising, or even give them money. The finesse comes in when we start trying to find the delicate balance between the user’s desire and the user’s price point . If you were in a bazaar, the fair exchange would be settled by haggling. On the web it often comes in a similar form albeit slower, in which the business puts up a price they suspect is too high (five page registration form) or too low (advertising-free) and then measures and adjusts as the market reacts. It’s scary, because of course users are answering the opening offer by walking away or by flocking in droves and crashing the servers. But with luck and some experimentation (and vigorous analytics) sites find the correct price point.
Rather than taking the near-socialist view many user-centered designers fall into, try think about what a fair market price is for the things the business wants from the user. Work with business to balance avarice with altruism.
It’s also critical to know what your business model is. Without this information, you have no idea which actions of the user are valuable and which are not. And without knowing that, you are as likely to spend hours working on an aspect of the website that delivers no value as one that does. This is not usually a fatal mistake in a large corporation (though sometimes it’s a firing offence), but in a start-up it can literally kill the company. The sidebar has a few common internet business models listed; see if you recognize yours and think what sorts of actions users need to take in order for the business to put bread on the table. This list is not meant to be definitive. Internet business models constantly change and adapt. Also, a company may combine several different models as part of its overall Internet business strategy, for example, a content driven business may blend advertising with a subscription model. Still this chart may help you think about how your company is able to write you a paycheck every two weeks.
|
Type of |
Description: |
|
Marketplaces bring buyers and sellers together and Services Broker — offers a full range of services covering the Auction Broker — conducts auctions for sellers (individuals or Transaction Broker — provides a third-party payment mechanism for |
|
|
The web advertising model is an update of the one Classifieds — list items for sale or wanted for purchase. Targeted Advertising — content-based sites that are free to access but Query-based Paid Placement — sells favorable link positioning (i.e., sponsored Content-Matched Advertising — pioneered by Google, it extends the precision of |
|
|
The affiliate model allows brokers and merchants Revenue Sharing — offers a percent-of-sale commission based on a |
|
|
The viability of the community model is based on user Open Source — software developed collaboratively by a global Open Content — openly accessible content developed Social Networking Services — sites that provide individuals with the ability |
|
|
Users are charged a periodic — daily, monthly or Content Services — provide text, audio, or video content to users who Software as a Service – Many services that would have typically been Internet Services Providers — offer network connectivity and related services |
(d) What – know your raw materials
1) Know your code
It doesn’t matter if you are an artist or an information architect; you have to know the materials with which you’re working. In art school, most painters will learn to stretch their own canvases and mix pigments; while they rarely continue this practice into their professional life it gives a deep understanding of the strengths and weaknesses of the materials.
It’s pretty much the same with the web, though replace canvas and paint with data and code. You really don’t have to know how to roll your own perl or java to be able to design a good website. Conversely, having built a page or two by hand in html will make a big difference in your understanding of what is possible. Redoing your blog templates, forcing an understanding of template-driven design is even better. Design your own database and you will be a force to be reckoned with.
But if you are dyslexic or disinclined, you can make up for a lack of coding chops by spending as much time as possible with the engineer you’re to be working with, to assure yourself that the solutions you are coming up with can be done in the real world. More than one designer has spend hours coming up with an amazing navigation system, only to discover it’s based on a piece of data not in the system. Doh! Moreover your engineer may come up with a solution more elegant that the one you’ve thought up, due to their insight into the possibilities inherent in code. Collaboration trumps dictatorships, especially on multidisciplary teams.
2) Know your delivery mechanism
When IA was born, it was pretty much a website only deal, viewed in browsers on computers. Since then data is a critical component of almost all applications, and applications are not only on computers, but on smart phones, kiosks and other devices as well. Sometimes you get the pleasure of customizing the interface to a unique device, other times you have to try to design a structure that’s robust enough to be reinterpreted by a soccer mom browsing for directions on her iphone on the freeway. Yep, make that interface easy or she may kill you with her SUV.
Mobile is a nice obvious case of an obstreperous delivery system, but don’t forget the complexity of a feature-heavy software program such as Microsoft Word? Is spellcheck under Edit or Tools? This is essentially an information architecture problem.
As well, iTunes is probably a best-known example out of a entire suite of data management tools. People who have never considered metadata or classification are designing playlists and inventing genres left and right in order to find the music on their ipods. Once upon a time information architecture and interaction design could ignore each other. But the peanut butter is in the chocolate now , and it’s here to stay. As you design content, consider the interaction. As you design interaction, consider the content.
3) Know the Content
We’ve (lightly) covered code, now let’s talk data. A critical aspect of knowing your materials is an understanding of the nature of the content of the web site. For example, if you are building a web site for a music store, it’s important to know the genres of music and the musicians. Imagine you are browsing through your local used CD store, and you come across Britney Spears in the Heavy Metal section. You are going to wonder what the heck is going on and if you will have to look through every section in hopes of finding that rare Ozzy Osbourne album you were seeking–it could be in Bluegrass for all you know. You may walk out and try the store next door instead of spending the next several hours searching.
To effectively classify the music on your music site, you have two choices:
- You can attempt to become an expert.
- You can work with people who are.
If the subject area is huge, it’s simpler to hire a subject matter expert (SME) to review your classification work than give up sleep for several weeks trying to learn everything about the world of music. If the subject area is relatively small, though, it may be worth learning its language and conventions.
To learn the subject area you can
- Interview subject matter experts. The guy down at the used record store really isn’t doing much between 10 a.m. and 11 a.m. and would probably chat with you in return for a cup of coffee delivered to the counter.
- Read books and magazines about the area. Slow, but paying extra attention to introductions, overviews, indexes, and tables of contents can help get you grounded and speaking the language. You can probably skim the rest.
- Conduct a landscape analysis. If you have direct competitors, you might want to look at how they handle their content. But if a lot of different kinds of web sites are working with the same type of content and issues related to that content as you are, you could get greater insight by broadening your research.
If you were designing a music store’s site, one of the questions you’d have to answer is, “How do I organize the music so people can find the songs and albums they want so they can then purchase them?” You might start by looking at a bunch of different music web sites: commerce sites, research sites, radio sites–maybe even fan sites. You would look for any place that might have solved the same problem you now face: how to organize and present music.
Suppose you are researching jazz in particular. There are a lot of good places to get ideas about how to organize jazz music (see Figures 3.1 through 3.3).
By stretching your search beyond the typical competitive analysis, you can gain a deeper understanding of the content you’ll be working with. Try taking it even further: pick up catalogs for music, visit physical music stores, and maybe even look into ticket companies’ organization schemes.
As well as looking at how the various sites label and organize their material, it is useful to look at features they offer, what type of content they show, and how they display it. This will give you a hint as to what others have found to work. You should not be afraid to learn from others and build from their knowledge. True innovation comes from understanding what’s been done in the past, why it works and why it doesn’t, and then seeking a solution. After all, BMW doesn’t reinvent the wheel every time it designs a new car, and it still manages to come up with some interesting vehicles.www.yahoo.com
FIGURE 3.1
Yahoo!’s directory is usually a good resource for organization options for big collections of information.
FIGURE 3.2
Pandora has eschewed traditional genre classification in favor of the “music genome”Landscape analysis is not a substitute for user research, however. User research can be a big help in understanding why it works and why it doesn’t. After you’ve done a landscape analysis, you probably have a huge list of questions about the choices others have made.
To get answers, you need to talk the potential end user.
Those People
A fable: You’ve spent the afternoon chatting with business, and you’ve discovered that they want eighty thousand people a day to come to their site, dumbjokes.com, read three jokes and then click on a banner.
You could collect the jokes, and stick them up on the site in a manner that you found pleasing and then wander off to the next project (the smellovision newsletter!). But then halfway through that project, the business people might knock on your cube complaining that half their eighty thousand leave, and the other half never even read one joke! And there is very little banner clicking. Suddenly smellovision is pushed back while dumbjokes.com gets a redesign.
So how are you going to avoid making the same mistake twice? Especially when you aren’t sure what the mistake was? User-centered design.
User centered design is pretty simple. Here are the basic steps:
- Figure out who the site is for
- Talk to those people
- Design the site for them
- Test a prototype of the site with them
- Test the final site with them
And voila! You are done. The secret to making a site that people dig is involving them throughout the process. Guessing what people want then building a site for them is expensive–you guess wrong, you have to do it all over again. But an informed guess… tested… then refined… may look more expensive in the project plan, but saves the big cash (and makes big money with happier customers) in the long run.
(c) Where do I start?
Who are you making the site for? This is usually the tricky one. A good place to start is with the marketing and business teams. Marketing has probably done a fair amount of research into demographics and hopefully even psychographics of the website’s users. Business usually knows the users they would like to reach as well. Set up a one hour interview with a couple people from each department and try to get as much information about the potential user base as possible.
Next you need to go talk to your potential site visitors. If you are doing a redesign, you are lucky. You probably already know who is coming to the site and can reach them through a variety of ways
- Ask for volunteers in your newsletter (if you have one)
- Ask for volunteers on your site
- Contact people via customer service
These are ways you can collect names of people to talk to. If you aren’t doing a redesign, you may need to hire a recruiter who specializes in finding people to talk to. If you do a search for “market research recruiting” you can probably find a firm. If you can’t afford a recruiter, you may have to get creative. Some people post on bulletin boards, some go to malls or grab people of the street. Depends on how bold you are. If you are talking to just anyone, though, you need to try to figure out if they are similar to your target audience. To do this, you can write a short questionnaire called a screener.
A screener is a set of questions that determine who you will be talking to. It’s based on your understanding of your current or potential audience. Let’s say you want to find eight people to talk to. Your site is 70% men and 30% women. So you pick five men and three women to talk to. Your site is an ecommerce site. So you ask people if they’ve bought anything online in the last year. Your site is a jokebook site. You can ask if people enjoy telling or listening to jokes. Now you have a group of people to choose from. Try to pick the most articulate for your research. People who only grunt when you ask them questions will probably be less helpful.
(c) I’ve got people, now what?
Talk to them. First you have to decide what to ask. You can write a quick script before your interview. Some good questions include
- What are other sites they visit
- How do they use your type of product
- Do they use competitor’s products?
- Explore interest in potential features.
- Do they use non-web version of the product?
With each of these questions be sure to have follow-up questions as well. So if they say they do use competitor’s products, ask who, and why. Ask them how they use the product. Try to get them to talk as much as possible.
Be careful when you write your questions. Try to make them neutral as possible. If you ask “Why do you hate dumbjokes.com,” you may be setting up the answer.
|
Question |
Follow up |
|
What are some of your favorite sites? |
How about entertainment sites? Where do you go for a |
|
Do you read jokes online? |
How about in email? How do you find those jokes? |
|
(if they haven’t mentioned it) Do you read |
If yes, do you like the jokes? How often do you go? |
|
Do you ever share jokes? |
How? Telling, emailing? |
|
How else do you get jokes? |
Do you have favorite books? Favorite comedians? |
|
Have you ever been to dumbjokes.com? |
If yes, what was your experience? If positive, ask what made it positive. If negative, ask what made it negative. Then ask if there was anything (positive, negative) |
|
Would you change anything about dumbjokes.com? |
If yes, probe for how. |
Now write down everything you’ve learned. Look for patterns. Do people have favorite joke sites? Look at those sites and see if you can learn from them. Are people interested in your feature ideas? Did people suggest new features that might be worth pursuing?
Also, when you are analyzing what you gathered, try to think about everything critically. If a person said he wanted a dancing joker on the front page who tells them the newest joke, you have to ask yourself “what does he really want?” What he really wants, probably, is an easy way to see if there are new jokes. There are a lot of good ways to design for that that don’t involve dancing jokers that might annoy other users.
Remember, you are not a scientist. You are not here to get statistical evidence proving one theory or another. You are here as a designer, trying to figure out the mental model people have for the world you are about to design. Use common sense to figure out what is one wacky guy’s opinion and what is probably representative of many users. If you aren’t sure, talk to more users. You could also do a survey to gather more information about a particular issue.
(c) Design a site for the people.
Go. Design. I’ll wait here.
(d) Test a prototype of the site with the potential users.
Prototyping is a way to get feedback without spending hours and hours coding a site. In fact, the site doesn’t even have to have a final visual design. You can test a rough layout of the site. It’s just a way to see if you’ve gotten the basic concepts right.
(e) How to Prepare a prototype test
Create a rough prototype of the product on paper. It doesn’t have to be perfect, and it can be missing parts if you aren’t sure how to handle a certain problem area. It’s useful to hand draw this prototype. Making prototypes with a computer often causes people to get caught up in designing and spend a lot of time fussing over a line, moving it a few pixels to the right or left. It also can feel so finished, the people you are testing with may feel nervous requesting changes. With hand drawing on paper, it’s clear it’s not the final product, and anyone can feel comfortable crossing out a label with a pen, or joking about a bad label.
Once you’ve drawn the basic pages, add in the interactive elements. Feel free to get creative. A piece of paper in an accordion fold makes a good dropdown list. You can use post-its for pop-up windows, and bits of colored paper for radio buttons.
Next, create a loose script outlining a few key tasks you wish the potential user to accomplish. Recruit people to test with in the same way you did for your interviews. Four people are probably plenty to get feedback.
Set up the schedule for the day. Be sure to schedule in time to catch your breath, and talk to the team between testing sessions.
Testing/ iterating the prototype
Testing a prototype is pretty much like a regular usability test.
***insert footnote
There are a number of great books on the subject. Check the reading list at the end to learn more about how to run a good test.
***end footnote
(f) Running the prototype test
You’ll need three people. A moderator, a note taker and a person to play computer.
The moderator asks the potential user of the site to try to accomplish tasks. Ask the user to pretend their finger is a mouse. When the user “clicks” a link by pointing to it with his finger, the “computer” picks up the right drawing of the screen that was requested. When the user “clicks a dropdown” the “computer” opens up the accordion fold. And so on.
As you go along, your note-taker should be watching for any problems, and noting potential solutions if one is apparent (either suggested by the user or by the team.) When the test finishes, make changes to any problem you believe to be universal i.e. not caused by that user’s particular temperament. This can be a tricky judgment, but remember you have more users coming, so if you change it wrongly, you’ll get a chance to change it back. After changes are made the note-taker should make a careful log of all the changes and why they were made. Bring in the next user and repeat the process.
(g) Analyzing rapid prototype test results
The final prototype will be as telling as any report you could write. Toward the end of the session you should be making fewer and fewer changes; and the changes should be minor refinements such as a label that can’t quite suit everyone. Write up a report summing up your discoveries for the members of the team who couldn’t be there, and include a copy of the final prototype. This final prototype should serve as the basis of your design.
You may want to do several prototype tests, either of different parts of the site, or different tasks, or at different stages of the product. Once you’ve got visual design done, it can be useful to turn it into simple html and test that as well.
(h) Test the final site with users.
Before launching, be sure to bring in those potential users one more time. This should be considered the equivalent of QA and only done as a sanity check–if you catch major problems at this stage it’ll cost three times more to fix than if you catch it when your design is paper. Usability testing should never be your only research tool. You should also test the current site anytime you are contemplating a redesign, just to determine what is baby and what is bathwater.
Now you’ve got a way to make sure your architecture will work.