Below are the 15 most recent journal entries recorded in sil_van's LiveJournal:

Saturday, March 19th, 2005
10:49 pm	Reviving Advanced Hypertext Summary: To manage a huge, worldwide information space, users need proven features like fat links, typed links, integrated search and browsing, overview maps, big-screen designs, and physical hypertext. Tim Berners-Lee's genius in inventing the Web in 1991 was to strip the hypertext concept to the bone and design a system with minimal features that worked across the Internet. The Web really has only one feature: uni-directional plain links that replace the existing page with a new one. Yes, the feature has twists, such as the ability to go back or open the link in a new window (which I recommend against), but fundamentally, the Web has no advanced hypertext capabilities. New Web Features Since the first hypertext systems in the 1960s, many more features have been invented and several turned out to be useful. Maybe it's time to implement some of these features for the Web. Fat Links Fat links are links that point to more than one page. Now that browsers like Firefox and Safari support tabbed browsing, it's possible to have a link that opens up multiple tabs, and thus lets users access several destinations in one click. Although many users like tabs, I'm personally less enamored of them, possibly because I use a fairly large screen (2048 x 1536 pixels). With a big screen, it's usually better to manage multiple pages in windows rather than in tabs. Taskbar usability improves because you can see more of the window title in the buttons on the bottom of the screen. Also, a big screen lets you display multiple Web pages simultaneously, which dramatically improves the usability of critical tasks like collect, compare, and choose. Still, tabs do have their advantages, and in any case, they're only one possible implementation of fat links. (Note: Bookmarks are a special kind of link; Firefox's ability to open all of a folder's bookmarks at once is thus a fat bookmark.) Typed Links If the user interface formally recognized different link types, it could display and manage them differently. The most obvious type distinction is between a website's internal links and links that point to other sites. Browsers could implement this distinction today by simply looking at the domain name in the URL: if you're displaying a page from foobar.com, links to foobar.com pages are internal and all others are external. A slightly more advanced system might recognize the possibility of a given company owning multiple domains. Many website designers have attempted to design icons that notify users about links to external sites, but these attempts usually fail because the designs are non-standard. Jakob's Law states that users spend most of their time on other sites and form their expectations based on their aggregated user experience. Thus, unless all sites have the same icons (and use them consistently), it's a doomed endeavor to visualize link typing with icons, rather than to embed types at a deeper system level. Of course, typed links could have many uses beyond the simple internal/external distinction. For example, browsers could treat destinations that require micropayment or registration differently than free links. Similarly, they could distinguish between links to arguments that support or refute a position. Explicit Structure Instead of treating atomic links and pages as the UI's only concepts, we could add an explicit representation of the information architecture. Opera already does this, giving users buttons to go to a site's home page, help system, category listings, and so on. The benefit of explicit structural commands is that they free users from slavery to individual site designs. Users need no longer suffer under bad sites. And, even on good sites, they can simply use a standard command that's always the same rather than spend time trying to comprehend each site’s navigation. That's a primary reason for the Back button's popularity: it lets you avoid searching the page for a link that might accomplish the same thing. User-Constructed Structure A particularly interesting form of structural UI is any structure that's built by the user and added on top of existing hypertext. Annotations and guided tours are two examples. Annotations superimpose user-generated content, such as text, doodles, or links to other sites. This structure has many uses, including simply letting you post reminders to yourself about your last experience with a site. Guided tours let you collect a series of pages and subsites and combine them with additional material into a new structure that you can communicate to others. This is great for e-learning applications, but also has more pragmatic uses. For example, you might research a business purchase and send your boss a guided tour with the pros and cons of different options. Integrated Search and Browsing Search is one of the main ways people access the Web, and it has the huge benefit of letting them explicitly state what they want during each visit. Unfortunately, users leave all information about their current queries behind as soon as they start browsing from the SERP (search engine results page). In 1990, Bell Communications Research's SuperBook project proved the benefits of integrating search results with navigation menus and other information space overviews. There are three basic approaches to this. The first is simply to annotate each navigation label with the number of search hits in the area it points to. A second, more advanced approach would use an indication of aggregated search relevance. A site might, for example, emphasize an area containing one extremely relevant page over an area with ten less relevant pages. In any case, the key is to give users a prospective view of the extent to which different navigation options relate to the current query. Also, once users arrive at a page, it's beneficial to highlight query terms. Doing so makes it easy for users to judge why the page was deemed relevant, and thus easier to decide whether to stay or leave. Highlighting query terms also helps users narrow their attention to the most relevant part of the page. A third approach to integrating search and browsing is to display higher-value advertising. If the site knows the user's most recent query, it can display ads related to those keywords instead of more generic ads. Of course, ads on content pages will never be as successful as the same ads on a SERP, because the user's behavior has changed from seeking to reading. While on the search engine, users are looking for someplace else to go, and thus are very likely to click on any ad that promises to solve the problem inherent in the current query. On a content page, that same ad conflicts with the user's goal to process the information and possibly return to the search engine to select the next destination. Still, an ad that's relevant to the user's current problem (as indicated by recent query terms) should beat advertising chosen with less situational awareness. Placing search ads on content pages should particularly benefit players -- like Yahoo! and MSN -- that combine search engines with networks of other services. Such sites can directly transfer their knowledge of user queries to the non-search parts of their network. Other sites might extract the user query terms from the referrer information that's usually received when visitors arrive from search engines. Or, search engines might stop passing along the current query string and start selling it as a separate data stream to destination sites. (Once we start transferring keyword relevance to post-SERP behavior, it will be interesting to measure how fast the user's intent diverges and thus how fast the value of targeting the previous intent decays. I would not be surprised if the keywords' value evaporated within five minutes. Web users are fickle.) Overview Maps In several studies of pre-Web hypertexts, having an overview map of the information space improved users' performance between 12% and 41%. Knowing where you are, where you've been, and where you can go is a significant help in navigating online information. Navigation menus and site maps are two common approximations of overview maps, but neither provides the full set of features that users need. Due to space constraints, navigation menus show only a limited view of users' options. Site maps don't highlight current location, partly because users must leave their current location to access the site map as a separate pageview. Certainly, it would help if designers followed the twenty-eight design guidelines for site map usability. But ultimately, designers must integrate overview diagrams with the browser to support three core features: You-are-here markers. Footprints showing where the user has been. Sites that change the color of visited links partly offer this feature, assuming their site maps use textual links. But even these sites don't provide two essential elements of footprints: Marking areas that the user has visited (even if the user hasn't been on the area's main page and thus hasn't seen the link's specific URL). Using differential markings that indicate the extent of the user's visit to an area (did you see all the pages in a subsite or only a few of them?). Search hit density markers, as discussed under "Integrating Search and Browsing." Big-Screen Design In principle, the Web is independent of screen size. But in practice, the Web is designed for a small-screen user experience, in which users view one page at a time at a narrow width (typically 800 or 1024 pixels). Scrolling is the main way users access information that can't be displayed on a small screen. Once we get screens the size and resolution of a broadsheet newspaper, the user interface will change. It will become possible to rely more on spatial hypertext and less on linear scrolling. In fact, the very concept of a page may vanish and be replaced by higher-level aggregate units that combine multiple data feeds. The prevalence of portlets on intranet portals is a weak precursor to the potential for integrating multiple information units that can be independently activated and updated. Physical Hypertext Rather than click underlined words on a screen, it's possible for users to retrieve a destination page through some real-world action. Physical objects can be the anchor points for a hypertext link. Several doomed projects have tried to implement physical hypertext on the Web. The most prominent and clueless was CueCat: a barcode scanner that let users scan magazine ads to display more information about advertised products. CueCat failed for two reasons: It benefited advertisers, not users, so people had little incentive for keeping a CueCat around for those rare occasions when they wanted follow-up info on an ad. Typing in a URL is easier than digging out a special hardware device. It was tied to the PC, so it didn't help people when they were shopping or otherwise might want information but didn't have PC-based Web access. Future projects for physical hypertext must overcome these two downsides. It will be easy to embed barcode scanners and RFID readers in mobile phones and other PDAs with Internet capability. Such devices will let users link off physical objects they encounter when they're out and about. Where should the links lead? Not just to ads, but also to other useful information, such as review sites or comparison-shopping sites that tell users whether they're getting a good deal. Collaboration Browsing is a solitary experience. Life isn't. I mention collaboration as my last feature, because it's the one for which old research provides the least guidance. There's some work on shared hypertexts, where people build up a collaborative knowledge base and/or solve other problems together. Wikis offer a primitive example of the power of multi-user hypertext. But mainly, collaboration remains a field with immense promise and little progress. Any Hope? In 1995, I listed fifteen hypertext features that were missing from Web browsers. None of these ideas have been implemented in the ten years since, except for Firefox's search box and Internet Explorer's search sidebar. Is there any hope that the next decade will bring more progress? I think so. For one, most of the ideas mentioned here are rich sources of user interface patents, which offer a sustainable competitive advantage. (I invented at least five potential patents while writing this article, but didn't bother filing because I'm not in the business of suing infringers; a big company could rack up the patents if so inclined.) The last ten years were a black hole: much attention was focused on doomed attempts at making the Web more like television. Hopefully, the next decade will focus instead on empowering users and giving us the features we need to master a worldwide information space. (Comment on this)
10:48 pm	Durability of Usability Guidelines Summary: About 90% of usability guidelines from 1986 are still valid, though several guidelines are less important because they relate to design elements that are rarely used today. The usability field is getting on in age, and we now have the cumulative wisdom of more than twenty years of user research at our disposal. Some usability enemies like to dismiss established findings, claiming, "they may have been true once, but not any more." Because the computer field does tend to move quickly, it's reasonable to ask whether old usability insights have indeed become obsolete. From 1984 to 1986, the U.S. Air Force compiled existing usability knowledge into a single, well-organized set of guidelines for its user interface designers. I was one of several people who advised the project (in a small way), and thus received a copy of the final 478-page book in August 1986. The project identified 944 guidelines. This may seem like a lot, but it pales against the 1,277 guidelines for Web and intranet usability we've identified so far--and we're not done yet. Twenty-Year-Old Guidelines--Past Their Expiration Date? The 944 guidelines related to military command and control systems built in the 1970s and early 1980s; most used mainframe technology. You might think that these old findings would be completely irrelevant to today's user interface designers. If so, you'd be wrong. I decided to use the 1986 report to assess the longevity of usability work. Because reassessing all 944 guidelines would require too much effort, I took a shortcut, reviewing ten guidelines from each of the report's six sections, for a total sample of sixty guidelines. (A sidebar reprints these sixty guidelines, so you can judge them for yourself.) Of those sixty usability guidelines, fifty-four continue to be valid today. In other words, 90% of the old guidelines are still correct. What's Changed Ten percent of the guidelines would have to be retracted or reconsidered for today's world. But even these questionable guidelines are at least partly correct in most cases. In fact, I would deem only two guidelines (3%) completely wrong and harmful to usability if followed. Guideline 4.2.6 said to provide a unique identification for each display in a consistent location at the top of the display frame. This guideline worked well in the target domain of mainframes: Users typically navigated only a few screens, and having a unique ID let them understand their current location. The IDs also made it easy for manuals and help features to refer to specific screens. Today, screen identifiers would clutter the screens with irrelevant information. They would not help modern users, who move freely among numerous locations. Even this invalidated guideline continues to contain a core of truth: it's good for users to know where they are and what they can do on each screen. The current recommendation is to provide a headline or title that concisely summarizes each screen's purpose. Guideline 3.1.4.13 said to assign a single function key to any continuously available feature. This made sense for mainframe interfaces because they relied extensively on function keys to speed up the interaction. Also, mainframe systems were so heavily moded that very few functions were available across all system areas; the few that were obviously deserved special treatment. Modern systems attempt to be modeless, so many features have become ubiquitous and accessible from anywhere. Furthermore, function keys are no longer the primary way of operating computers. Given these two changes, it no longer makes sense to assign function keys to constantly available features. In addition to the invalid guidelines, twenty percent of guidelines are essentially irrelevant today because they relate to rarely used interface technologies. For example, guideline 1.4.13 discussed how to overtype the field markers (typically underscores) that mainframe systems used to indicate where users could type their input. Today, input fields are almost always denoted by text entry boxes, so knowing how to improve a field marker's usability is largely irrelevant. What's Still Valid Of the 944 guidelines from 1986, 70% percent continue to be both correct and relevant today. There is much good advice, for example, on dealing with entry fields and labels on online forms, which have changed little from the dominant mainframe designs of the 1970s. The guidelines on using business graphics to display different types of data are also highly relevant today. In our recent studies of how investors and financial analysts use the investor relations area of corporate websites, we found many usability problems related to overly complex charts. Following twenty-year-old guidelines for charting numbers would have improved many IR sites considerably. The guidelines for error messages, system feedback, and login also hold up. It was interesting to see that guideline 6.2.1 recommended single sign-on. In our intranet usability measurements, we found that login difficulties (mainly due to multiple sign-in requirements) accounted for the second-largest difference in employee productivity between intranets with good usability and those with poor usability. (Search usability constituted the biggest difference between good and bad intranets.) Too bad most systems still lack the login interface recommended in 1986. Luckily, other aspects of user interface design have advanced. Several of the guidelines for messaging interfaces continue to be both valid and relevant, but are hardly revolutionary today: almost all email systems follow them to the letter. This is an example of usability insights becoming so firmly entrenched that they change from "best practices" to "the way things are always done." If anything, it's sad that so few of the findings from 1986 have made this transition. Why Usability Guidelines Endure You would be hard-pressed to find any other Air Force technical manual from 1986 that's 70% correct and relevant today. Whether for pilots, airplane engineers, or programmers, general lessons of the past might continue to apply, but the specific guidelines changed long ago. Usability guidelines endure because they depend on human behavior, which changes very slowly, if at all. What was difficult for users twenty years ago continues to be difficult today. People can only remember so many things, and we don't get any smarter. I recently analyzed my own old guidelines for Web usability, as published on the Alertbox and elsewhere in the early days of the Web. Of those early guidelines, 78% continue to be valid and relevant. Of course, my early guidelines are only ten to eleven years old, so it's hardly surprising that they'd score better than twenty-year-old guidelines. Usability guidelines mainly become obsolete when they're tightly bound to specific technologies. For example, neither the 1986 field marker guidelines nor my 1995 guideline on making hypertext links blue held up. (More recent guidelines for link colors offer updated recommendations.) However, the corresponding underlying usability principles do hold: ensure that users know what they can do and that they can recognize actionable user interface elements. Posterity vs. the Present The more permanent guidelines tend to be those that are the most abstracted from technology. I'm nonetheless under strong pressure from readers to make usability guidelines as specific as possible so that they're easier to apply. In resolving the tension between eternal truth and short-term application, it's often tempting to err on the side of serving current rather than future readers. The lure of the present is especially strong when writing for the Web. In writing a book, I'm highly conscious of people who will be reading my text ten or more years into the future. But when posting to my website, I tend to write for today's readers, even though 80% of the pageviews will occur after an article has passed into the archives. Luckily, most of my old analyses hold up pretty well, and ten-year-old articles continue to be 78% relevant. However seductive the present might be, writing for the Web is writing for the ages, not just for the moment. (People who post stream-of-consciousness entries in their weblogs, for example, might want to consider that they're also writing for managers who might hire them in twenty years.) Usability guidelines have proven highly durable, and most hold true over time. Present-day designers should not dismiss old findings because of their age. Today's Guidelines I'll present the principles behind my most important current guidelines in the Fundamental Guidelines for Web Usability seminar at the Usability Week 2005 conference in New York, Stockholm, London, and San Francisco. (1 Comment |Comment on this)
10:47 pm	Authentic Behavior in User Testing Summary: Despite being an artificial situation, user testing generates realistic findings because people engage strongly with the tasks and suspend their disbelief. It's a miracle that user testing works: You bring people into a room where they're surrounded by strangers, monitored by cameras, and asked to perform difficult tasks with miserable websites. Often, there's even an intimidating one-way mirror dominating one wall. Under these conditions, how can anybody accomplish anything? In fact, all experience shows that people can and do use websites and other user interfaces during test sessions, and that many valuable usability findings emerge from such studies. Why? Two main reasons: the power of engagement and the suspension of disbelief. User Engagement When test participants are asked to perform tasks, they usually get so engaged in using the interface that the usability lab's distractions recede. Users know that there's a camera, and maybe even a one-way mirror hiding additional observers, but their attention is focused on the screen. It's a basic human desire to want to perform well on a test. We can say, "we're not testing you, we're testing the system" all we want. People still feel like they're taking a test, and they want to pass. They don't want to be defeated by a computer. Because they want to be successful, users allocate their mental resources to what's happening on the screen, not what's happening in the room. Of course, this concentration can easily be broken, which is why it's a cardinal rule of user testing to have observers remain absolutely quiet if they're in the room with users. Also, in fancy usability labs, I've seen users distracted by the noise of cameras moving along ceiling tracks, so that type of thing is best avoided. But, generally, as long as observers stay quiet and out of view (behind the user or behind the mirror), participants will remain engaged in their tasks. One downside of users' tendency to engage strongly is that they sometimes work harder on tasks in a test session than they would at home. If the user says, "I would stop here," you can bet that they'd probably stop a few screens earlier if they weren't being tested. Suspension of Disbelief In user testing, we pull people away from their offices or homes and ask them to pretend to perform business or personal tasks with our design. Obviously, an artificial scenario. As part of the full usability life cycle, there are good reasons to conduct field studies and observe users' behavior in their natural habitats. Unfortunately, field studies are much more expensive than lab studies, and it's typically difficult to get permission to conduct research inside other companies. During a design process, most usability sessions involve user testing; we're therefore lucky that users can typically overcome a lab's artificial nature and pretend to be at home. The tendency to suspend disbelief is deeply rooted in the human condition, and may have developed to help prehistoric humans bond around the camp fire in support of storytelling and magic ceremonies. In the modern world, TV shows like Star Trek only work because of our propensity to suspend disbelief. Consider the number of untruths involved in watching Star Trek: You're not looking at people, you're looking at pictures of people, in the form of glowing dots on a picture tube. You're not looking at pictures of real people, you're looking at pictures of actors pretending to be characters, like Mr. Spock and Captain Picard, that don't exist. You're not looking at pictures of actors using transporters, shooting phasers, and flying faster-than-light starships. All such activities are simulated with special effects. You know all of this, and yet you engage in the story when watching the show. Similarly, in usability studies, participants easily pretend that the scenario is real and that they're really using the design. For this to happen, you obviously need realistic test tasks and to have recruited representative users who might actually perform such tasks in the real world. Assuming both, most usability participants will suspend disbelief and simply attempt the task at hand. Suspension of disbelief goes so far that users engage strongly with paper prototypes where the user interface is purely a piece of paper. As long as you can move through screens in pursuit of your goal, you will behave as if the system were real and not simulated. In fact, sometimes users go too far in suspending disbelief and try to role play other users' potential performance. You must put a stop to this immediately, as soon as you hear users speculate about what "some people" might do or might not know. Politely tell such users that you're testing many other people as well, but that you invited them to the test because their personal experiences are very important to the project. You can say to such users, "be yourself" and that "you know what you know," then ask them to use their own job situation as the usage scenario's background legend. When Engagement and Suspension of Disbelief Fail User testing typically works, but there are exceptions. Occasionally, test participants are so lazy and difficult to engage that they never suspend disbelief and work on the tasks for real. For example, if you ask such users to select a product to solve a problem, they'll typically stop at the first remotely related product, even if it's basically unsuitable and wouldn't be bought by anybody who really had the target problem. In rare cases, such nonrealistic usage is serious enough that you must simply excuse the participant and discard the session's data. If users haven't suspended disbelief and performed conscientiously, you can't trust that anything they've done represents real use. More commonly, you can rescue the situation by employing a few facilitation tricks to encourage authentic behavior. The easiest and most common approach is to ask the user whether this is what he or she would do at the office (or at home, for a consumer project). This small reminder is often enough to get users engaged. Variants of this technique include: Ask users if they have enough information to make a decision (when they stop after finding the first nugget of information about the problem). Ask users if they are sure that they've selected the best product (if they stop after finding the first likely purchase, without evaluating alternative options). If users fail to take the tasks seriously in your first few test sessions, you can usually rescue the study by modifying the test instructions or task descriptions. For example, it's often enough to add an introductory remark such as, "Pretend that you must not only find the best solution, but justify the choice to your boss." Including an absent boss in the test scenario encourages suspension of disbelief and usually works wonders. I've also found it effective to ask users to "write five bullet points for your boss, explaining the main pros and cons of this product." (You can also ask for three bullets of pros and three bullets of cons.) In our tests of the investor relations areas of corporate websites, we used a variant of this technique, simply asking the financial analysts and individual investors to decide whether they thought the company would do better or worse than the stock market and state the main reasons why. Other times, you can induce constraints to better engage users with the task. For example, we once tested an e-commerce site that sold office supplies. In pilot testing, a test task for administrative assistants was to stock the office for a newly hired employee. Unfortunately, the pilot participant wanted to be really nice to this hypothetical new colleague, and bought all the most expensive pens, office chairs, and so on. Although in this case, we could have asked users to pretend that they had to answer to the boss, we chose instead to give them a specific budget. This small change was enough to make users consider each item carefully, which let us discover how they assessed product quality and value. Despite the artificial nature of user testing, we typically see enough authentic behavior to easily identify design flaws that would diminish an interface's value for real customers. Getting to actually use something is so powerful an experience that most users provide good data. When they don't, you can typically prod users lightly with verbal reminders, or alter the task a bit to get them fully engaged. Learn More Topics such as user testing, participant recruiting, writing good test tasks, and facilitating test sessions are all covered in depth in my three-day camp on usability in practice at the upcoming Usability Week conferences in New York, Stockholm, London, and San Francisco. Intensive in-house three-day workshop on user testing for your team, where we test your own design as the case study. (Comment on this)
10:47 pm	Ten Best Intranets of 2005 Summary: On average, this year's winning intranets increased site use by 149% with designs that supported bigger screens, multinational users, collaboration, easily updated content, and factory-floor workers. Selecting the ten best intranets gets harder every year because the number of great designs keeps increasing. While tough on the judges, this is good news: it shows that the intranet usability movement is winning. More and more companies are treating their intranets as productivity tools and are investing in improving their design's usability instead of leaving the intranet to grow as it may. The recommendations from our previous intranet-usability reports are now being widely implemented. This year's designs were so good that our list of runners-up included at least ten additional intranets that were worthy of being recognized, featured, and emulated. However, a top-ten list can only include ten winners, so we had to select the best of the best. The Winners The world's ten best intranets for 2005 are: Banco Español de Crédito (Banesto), the third largest bank in Spain Cisco Systems, the world's leading computer networking vendor (U.S.) Electrolux, the world's largest manufacturer of powered appliances (Sweden) The Integer Group, the seventh largest promotional marketing agency (U.S.) NedTrain, the Dutch National Railway's maintenance subsidiary (The Netherlands) Orbis Technology, a small software developer (U.K.) Park Place Dealerships, operator of ten luxury automobile dealerships (U.S.) Procter & Gamble, a leading manufacturer of branded consumer goods (U.S.) Schematic, an interactive design and technology agency (U.S.) Verizon Communications, a leading telecommunications company (U.S.) Cisco is particularly remarkable because its sales-support intranet application was among the 2001 winners. This year, Cisco won for its overall intranet design. Schematic won for its extranet connecting employees, clients, contractors, and vendors. The other nine winners are internal-use intranets. Sweden seems to have the world's highest concentration of intranet design talent relative to the size of its population: it now accounts for 8% of the fifty intranets that have won our design competitions since 2001. An impressive achievement for a small country. The U.K. retains second place, with 10% of the winners since 2001. The United States continues to have the most winners. In general, however, we continue to find good intranets from over the world; this year's winners represent five different countries. Four of the winning intranets support relatively small companies with less than 1,200 employees. Two others are mid-sized, with 4,000 to 10,000 employees, and four are big, with 34,000 to 236,000 employees. The winning intranet teams range in size from one person at Park Place Dealerships to twenty people at Cisco and twenty-four at Verizon. Advanced Design Concepts This year, several intranets were designed to work best at a 1024 x 768 screen resolution. Intranets have an advantage over websites here, as organizations often give all employees the same sized monitors. At Banesto, for example, all bank employees have standard-issue monitors that support 1024 x 768 resolution. The intranet designers used this wider screen space to good effect, implementing a homepage with multiple columns in a layout that would feel cramped on a smaller screen. In the future, we expect to see much bigger screens, starting in knowledge-focused small and mid-sized companies, which will get the most substantial productivity gains from including more data within the visual field. Except for slightly boring examples (such as spreadsheets), we've yet to see many good examples of interfaces optimized for screens that are 2,000 pixels wide or more. In the coming years, advanced intranets might well be pioneering these broad-canvas designs. Intranets are already pioneering the use of online video, which websites rarely use to good effect (aside from movie trailers). Intranets can take advantage of one of video's key benefits: it can show a speaker's personality. Several winning intranets use video to strengthen the corporate culture through messages from the CEO and other executives. Because video messages carry both information and emotion, they can convey the multiple layers of a CEO's message. Among this year's winners, the Integer Group has perhaps the most elaborate online videos, often produced in a highly original style in which the company's Denver-agency president makes fun of himself. Although that specific tone might not fit as well in more staid organizations, the general idea of highlighting personality and illustrating corporate culture by example definitely translates. Orbis has probably the most unusual intranet approach, building its site entirely on a Wiki platform. In this collaborative authoring environment, any employee can edit any page at any time (except for a few modification-controlled pages). As a result, employees can easily and immediately update information whenever they come across outdated content. The result is that the Orbis intranet is much more richly informative and current than what is typical for small organizations with limited intranet resources. Even companies that don't want to completely open up edit-access can benefit from making department- and project-level pages easier to edit. Beyond The Office Intranets began as document repositories and soon grew into support tools for office workers. We are now starting to see intranets move beyond this desk-bound role to take on the world beyond the office. Four of this year's winners (Electrolux, NedTrain, Procter & Gamble, and Verizon) offer kiosk-based intranet access for factory-floor workers and others who work outside an office environment. These kiosks are basically traditional PCs on stands, maybe slightly ruggedized to withstand dust and grease. In the future, we hope to see a new kind of user interface developed for workers who are not routinely exposed to computers. It's difficult to ensure good usability for blue-collar workers when you're building on top of a UI platform optimized for office use. Several of this year's winning intranets have special applications to support the physical environment. For example, NedTrain has a real-time list of available train parts, the most important piece of information it needs to keep its trains running. On the Park Place Dealerships intranet, the Client Concern Resolution system proactively contacts managers -- such as the repair shop's foreman -- who would otherwise be hard to locate. By enabling electronic communication with important employees who are highly mobile, this feature expedites customer service, which is much appreciated by the demanding clients of these luxury dealerships. Internationalization Several of the winning intranets support employees in multiple countries, and Electrolux and Procter & Gamble have made internationalization a core design element. P&G provides an especially impressive location-change tool that employees can use to control the intranet's language and location-dependent information, such as HR policies. Having one place to define location-based settings beats the typical scenario, in which employees must wade through information about multiple locations in multiple languages in order to find the appropriate documents. In addition to its English-language pages, Electrolux supports localized portals in French, German, Hungarian, Italian, Portuguese, Spanish, and Swedish. To ease collaboration across time zones, the company also provides a handy reminder of the current time-of-day at three main locations (Sweden, eastern United States, and Sydney, Australia) at the top of every page. Technology Confusion The only conclusion regarding intranet technology platforms is that there is no conclusion. No single solution dominates the space. In fact, most winners didn't even build their intranet from a single, integrated platform. Typically, designers cobbled together widely diverse software using little more than spit, bailing wire, and willpower. In total, the ten winners used thirty-nine different technology products. Most winners also feature a significant amount of homegrown software in their overall intranet technology platform, confirming the conclusion that it's still not possible to buy everything you need for a great intranet. The most-used technologies were Apache, Microsoft ASP.Net, and Microsoft SQL Server. Other often-used technologies included Documentum, Google Search Appliance, IBM WebSphere, and Java 2 Enterprise Edition (J2EE). Some winners relied strongly on solutions from HP or IBM, and one winner was a committed Microsoft-only shop. Open-source software also made a strong showing this year. Beyond the heavily used Apache, winners used Eclipse, Linux, Mambo, MySQL, PHP, PostgreSQL, and TWiki. All that said, we do see some progress in intranet technology platforms: solutions are emerging that support more of the necessary design elements and these solutions are becoming easier to integrate. For example, plug-in search engines are easier to handle than past search packages, which required extensive hacking before they could spit out decent results. Still, a significant opportunity remains for software vendors who truly understand the needs of intranet users and intranet teams. Design Process The average time between redesigns for this year's winning intranets was 29 months. This is about the same as we've seen in earlier years: the typical time between redesign rounds is between 2.5 and 3 years. What's new is that companies have dramatically expedited the redesign process itself. This year, the average project duration was a brief 7.6 months; in earlier years, redesigns typically lasted between 11 and 13 months. In fact, as the following chart shows, projects have moved progressively faster since we began our intranet design competitions. (Data on redesign duration is unavailable for 2001.) Why are design projects moving faster? One reason is that technology solutions have in fact improved, making it easier to build what you want. Another reason is that we know more about intranets. As a result, we can concentrate resources on improvements that really matter to users and on getting the key changes out faster, while deferring less important ones. The chart also shows a substantial increase in the number of different usability methods employed during redesign projects over the last five years. The fact that designers have more than doubled their usability methods, while decreasing their redesign cycle time by six months, is striking proof that usability doesn't have to delay project launch. The 2005 winners used an average of 4.5 different usability methods. The most-used method was user testing, employed by 80% of this year's winning projects. Other heavily used methods included card sorting and heuristic evaluation, both of which were used by 50% of the projects. In the past, few projects used heuristic evaluation. In 2001 and 2002, only 10% of the winners used the method, which basically involves judging a user interface relative to known usability principles. The recent growth of heuristic evaluation for intranets makes sense, because we have only recently established comprehensive intranet usability guidelines. It's now possible to review an intranet design relative to a list of important intranet usability issues. Prior to 2003, this was possible for websites, but not for intranets. In general, we recommend using a variety of methods at different project stages, starting with field studies and tests of the old interface to set the new design direction. Next comes iterative design and testing with users. Few design projects fully follow this recommended user-centered design process, but in tracking good design projects over the years, we've seen more projects get increasingly closer. Improvement Metrics Averaged across the winners, intranet use increased by 149% following redesign. Organizations typically measured usage in terms of pageviews or user sessions per month. Intranets are discretionary-use environments; employees only visit them if they feel it's worth their time. Thus, increased use is a good indicator that a redesign is providing recognizable value to employees. That said, pageviews are not a fully satisfying ROI metric because it's hard to estimate the monetary value of the increased use. Some types of use translate more directly into cost savings. Verizon, for example, saw the number of employee self-service transactions grow from 1.3 million to 6.3 million per year after it improved its intranet's usability. On a smaller scale, Schematic saves $100,000 per year on express shipments to clients and other partners now that they can directly view their project's progress on the extranet. This type of cost savings comes as hard dollars that are easy to count. Quantifying the productivity gains from increased intranet usability requires a formal benchmarking study, which few organizations bother conducting. Thus, even good intranet teams usually don't have complete estimates of how much money they save their organizations. Cisco is one of the rare exceptions. The company's intranet team collected time-on-task measurements for employees using the old and new intranet designs to perform fifteen representative tasks. Overall, the average task took 17.6 seconds less with the new design. When considering total intranet usage, this faster performance saves Cisco $3 million per year simply from the reduced time it takes employees to navigate from the intranet homepage to a subsite. The gains from improving subsite usability will probably be even greater. Cisco also improved its user success rate across the test tasks by 2%, increasing it from 87% to 89%. This improvement might seem modest, but the higher the success rate gets, the harder it is to increase. The fact that Cisco's old design had an 87% success rate indicates that it was already very good; we usually see substantially lower success rates in our studies. As this example shows, even great designs can get better with close attention to usability -- and small improvements can be worth millions. In real life, it's infeasible to expect a 100% success rate, but it's definitely possible to add a few percent with a good redesign. Across a big company, that's a lot of additional employee tasks you can empower each year. The average intranet project, which sits at the 60% or 70% success level, should expect even bigger improvements: low-hanging fruit is very real given the current state of intranet usability in most organizations. As the ten winners show, it's possible for intranets to achieve a level of excellence lacking in most companies, and it doesn't require a lot of time to realize major usability improvements. (Comment on this)
10:45 pm	(useit) Low-Literacy Users Summary: Lower-literacy users exhibit very different reading behaviors than higher-literacy users: they plow text rather than scan it, and they miss page elements due to a narrower field of view. We've known since 1997 how most users read on the Web: they scan text and pick out the pieces that interest them. Content usability guidelines have remained mostly the same since 1997, but now there's news. We recently expanded our research to cover a big part of the population left out of earlier studies: lower-literacy users. As it turns out, their online behavior is radically different than that of higher-literacy users. This new research on lower-literacy usability is sponsored by Pfizer, which has a major effort underway to make its consumer communications understandable and actionable by a broad consumer audience. Understanding health information can be challenging for anyone, regardless of literacy level, so the effort's benefits will be far reaching in helping consumers understand and treat their conditions. Lower-Literacy Users: Characteristics Lower literacy is different than illiteracy: people with lower literacy can read, but they have difficulties doing so. The most notable difference between lower- and higher-literacy users is that lower-literacy users can't understand a text by glancing at it. They must read word for word and often spend considerable time trying to understand multi-syllabic words. Lower-literacy users focus exclusively on each word and slowly move their eyes across each line of text. In other words, they "plow" the text, line by line. This gives them a narrow field of view and they therefore miss objects outside the main flow of the text they're reading. Unlike higher-literacy users, lower-literacy users don't scan text. As a result, for example, they can't quickly glance at a list of navigation options to select the one they want. They must read each word in each option carefully. Their only other choice is to completely skip over large amounts of information, which they often do when things become too complicated. Lower-literacy users tend to satisfice -- accept something as "good enough" -- based on very little information because digging deeper requires too much reading, which is both challenging and time consuming. As soon as text becomes too dense, lower-literacy users start skipping, usually looking for the next link. In doing so, they often overlook important information. In addition, having to scroll breaks lower-literacy users' visual concentration because they can't use scanning to find the place they left off. Finally, search creates problems for lower-literacy users for two reasons. First, they often have difficulty spelling the query terms. Second, they have difficulty processing search results, which typically show weird, out-of-context snippets of text. As a result, lower-literacy users often simply pick the first hit on the list, even if it's not the most appropriate for their needs. Improving Usability for Lower-Literacy Users The main and most obvious advice is to simplify the text: use text aimed at a 6th grade reading level on the homepage, important category pages, and landing pages. On other pages, use text geared to an 8th grade reading level. You can also improve your site's usability for lower-literacy users in several other ways. Prioritize information. Place the main point at the very top of the page, where even readers who typically give up after a few lines will see it. Place any other important information above the fold, to minimize the risk of users losing their place after scrolling. This is always good practice; even the most skilled readers will leave a page if the first few paragraphs don't seem valuable. It's even better to avoid scrolling all together (which also helps teenagers) unless eliminating it requires you to chop content into unnaturally short sections, which can be even more confusing. Avoid text that moves or changes, such as animations and fly-out menus. Static text is easier to read. This guideline also helps international users (who might need to look up words in a dictionary) and users with motor skills impairments (who have difficulty catching things that move). Streamline the page design. Place important content in a single main column, so users don't have to scan the page and pick out design elements in a two-dimensional layout. This guideline also helps low-vision users and users of handheld devices (such as smartphones), which narrow the field of view. Simplify navigation by placing the main choices in a linear menu. This helps users clearly understand the next place to go, without requiring them to scan the page for options. Optimize search. Make your search tolerant of misspellings (which also helps seniors, who are particularly prone to making typos). Ideally, a user's first search hit should answer the query, and all hits should provide short, easy-to-read summaries. How Big Is the Lower-Literacy Population? According to the U.S. Department of Education's National Adult Literacy Survey, 48% of the U.S. population has low literacy. (Literacy levels are roughly the same in other advanced countries, though slightly higher in Scandinavia.) For obvious reasons, Web design is concerned only with Web users, and not the population at large. Generally, people with lower-literacy tend to use the Internet less than people with higher-literacy. Based on the available information about Internet participation at different education levels, I estimate that 30% of Web users have low literacy. Because most of the higher-literacy population is already online, however, future growth in Internet usage will mainly come from adding lower-literacy users. Thus, in five years or so, lower-literacy users will probably be 40% of Web users. Who Should Care about Lower-Literacy Users? Long experience shows that improving usability for users with disabilities typically increases usability for non-disabled users as well. Similarly, improving websites for lower-literacy users can also help higher-literacy users. That said, some sites are targeted mainly at higher-literacy users: B2B sites that target business professionals, managers, and decision-makers E-commerce sites that sell expensive or intellectual products The public relations and investor relations areas of corporate sites Content sites that cover scientific or other advanced topics Intranets for knowledge workers My own Alertbox column contains B2B content aimed at business professionals and executives who recognize usability's importance. I usually write it at a 13th grade reading level, which is not only far too difficult for lower-literacy users, but too complicated for the mainstream B2C audience. Given my readership, this readability level is acceptable. However, sites that target a broader audience must make lower-literacy users a priority. Such sites include: Government sites, especially those for senior citizens or the unemployed Health sites Companies that sell mass-market products HR info and benefits applications on intranets for companies with many blue-collar workers Case Study: What's at Stake? To estimate the impact of writing for lower-literacy users, we collected usability metrics before and after the website content for a major pharmaceutical product was rewritten and simplified according to the new guidelines. We tested the two website versions with fifty users, including both lower- and higher-literacy users. We conducted between-subjects testing using a double-blind protocol where neither the users nor the experimenters knew whether they were testing the original or the revised site. As the following tables show, we collected three usability metrics: success rate (whether people could perform the tasks), the total time needed to complete seven representative tasks, and the users' subjective satisfaction as rated on a questionnaire following the test session. Success Rate Original Site Rewritten Site Lower-literacy users 46% 82% Higher-literacy users 68% 93% Total Task Time Original Site Rewritten Site Lower-literacy users 22.3 min. 9.5 min. Higher-literacy users 14.3 min. 5.1 min. Satisfaction (1-5 scale, 5 best) Original Site Rewritten Site Lower-literacy users 3.5 4.4 Higher-literacy users 3.7 4.8 The revised site clearly had dramatically better usability on all three metrics: users got more correct information, did so faster, and liked the site better. All of the differences between the two sites are statistically significant at the p<.05 level. Lower-literacy users increased their performance by 135% in terms of how quickly they could complete the tasks, which is a major predictor of users' willingness to stay on a site. On all three usability metrics, the lower-literacy users scored better with the revised site than the higher-literacy users did with the original site. At the same time, the improvements for lower-literacy users did not come at the expense of higher-literacy users. In fact, the higher-literacy users also scored higher on all three usability metrics when using the revised site. People capable of understanding complex information nonetheless preferred more straightforward health information. The original site was designed by a respected agency and was certainly not bad: it scored a 68% success rate for higher-literacy users, which compares favorably with the 66% average in our latest broad-ranging usability study. (That study didn't include lower-literacy users, so we can only compare the numbers for people with higher-literacy.) Similarly, the original site's subjective satisfaction rating of 3.7 is higher than the average satisfaction score across the 184 websites we have tested recently. In summary, revising the text for a broad consumer audience made a good site excellent and benefited all users. The magnitude of improvement was huge: usability isn't a small tweak at the margins -- it doubles a website's ability to meet its goals. (1 Comment |Comment on this)
10:44 pm	Card sorting: a definitive guide Introduction Card sorting is a technique that many information architects (and related professionals.) use as an input to the structure of a site or product. With so many of us using the technique, why would we need to write an article on it? ----- “Card sorting is a great, reliable, inexpensive method for finding patterns in how users would expect to find content or functionality.” ----- While card sorting is described in a few texts and a number of sites, most descriptions are brief. There is not a definitive article that describes the technique and its variants and explains the issues to watch out for. Given the number of questions posted to discussion groups, and discussions we have had at conferences, we thought it was time to get all of the issues in one place. This article provides a detailed description of the basic technique, with some focus on using the technique for more complex sites. This article does not cover some issues such as the use of online tools, which will be covered in a future article. Why Card sorting is a quick, inexpensive, and reliable method, which serves as input into your information design process. Card sorting generates an overall structure for your information, as well as suggestions for navigation, menus, and possible taxonomies. While card sorting might not provide you with final structure, it can help you answer many questions you will need to tackle throughout the information design phase. For example, more than likely there will be some areas that users disagree on regarding groupings or labels. In these cases, card sorting can help identify trends, such as: Do the users want to see the information grouped by subject, process, business group, or information type? How similar are the needs of the different user groups? > How different are their needs? How many potential main categories are there? (typically relates to navigation) What should those groups be called? Card sorting can help answer these types of questions, making you better equipped to tackle the information design phase. Definition Card sorting is a user-centered design method for increasing a system’s findability. The process involves sorting a series of cards, each labeled with a piece of content or functionality, into groups that make sense to users or participants. According to Information Architecture for the World Wide Web, card sorting “can provide insight into users’ mental models, illuminating the way that they often tacitly group, sort and label tasks and content within their own heads.” Card sorting is a great, reliable, inexpensive method for finding patterns in how users would expect to find content or functionality. Those patterns are often referred to as the users’ mental model. By understanding the users’ mental model, we can increase findability, which in turn makes the product easier to use. Method There are two primary methods for performing card sorts. Open Card Sorting: Participants are given cards showing site content with no pre-established groupings. They are asked to sort cards into groups that they feel are appropriate and then describe each group. Open card sorting is useful as input to information structures in new or existing sites and products. Closed Card Sorting: Participants are given cards showing site content with an established initial set of primary groups. Participants are asked to place cards into these pre-established primary groups. Closed card sorting is useful when adding new content to an existing structure, or for gaining additional feedback after an open card sort. Closed card sorting will be detailed in a future article. Advantages and disadvantages As with any other method, card sorting has both advantages and disadvantages. Keeping these in mind will help you determine whether the technique is appropriate for your situation and make decisions about how you run the activity. Advantages Simple – Card sorts are easy for the organizer and the participants. Cheap – Typically the cost is a stack of 3x5 index cards, sticky notes, a pen or printing labels, and your time. Quick to execute – You can perform several sorts in a short period of time, which provides you with a significant amount of data. Established – The technique has been used for over 10 years, by many designers. Involves users – Because the information structure suggested by a card sort is based on real user input, not the gut feeling or strong opinions of a designer, information architect, or key stakeholder, it should be easier to use. Provides a good foundation – It’s not a silver bullet, but it does provide a good foundation for the structure of a site or product. Disadvantages Does not consider users’ tasks – Card sorting is an inherently content-centric technique. If used without considering users’ tasks, it may lead to an information structure that is not usable when users are attempting real tasks. An information needs analysis or task analysis is necessary to ensure that the content being sorted meets user needs and that the resulting information structure allows users to achieve tasks. Results may vary –The card sort may provide fairly consistent results between participants, or may vary widely. Analysis can be time consuming – The sorting is quick, but the analysis of the data can be difficult and time consuming, particularly if there is little consistency between participants. May capture “surface” characteristics only – Participants may not consider what the content is about or how they would use it to complete a task and may just sort it by surface characteristics such as document types. When should card sorting be used? Card sorting is a user-centered, formative technique. It should be used as an input to: designing a new site designing a new area of a site redesigning a site Card sorting in the overall design process. Click to enlarge. Card sorting is not an evaluation technique and will not tell you what is wrong with your current site. Card sorting is not a silver bullet to create an information structure. It is one input in a user-centered design process and should complement other activities such as information needs analysis, task analysis, and continual usability evaluation. It is most effective once you have completed: research into what users need out of the site a content (functionality) audit/inventory (for an existing site) or detailed content list (for a new site). For an existing site, it is crucial that the content inventory is examined carefully to include only content that is needed by users. Card sorting will provide benefit to most sites, but can be challenging to use against some sets of information. The table below summarizes when card sorting works well and provides good results, and when it is challenging both to run and to analyze. Easy Challenging Site size Small Large Type of content Homogeneous (e.g., product catalogues, lists of services, directories of web sites) Heterogeneous (e.g., intranets, government web sites) Complexity of content Participants understand most of the content Complex or specialist content Table 1.1 For sites with characteristics listed in the last column, card sorting will provide less direct input into the information structure; you may need to undertake a range of card sorts and more user-centered design activities. Card sorting can be useful to demonstrate to people that others think differently. We have successfully included it as an exercise in workshops for web site and intranet authors. Preparation Preparing for a typical card sorting exercise requires the following: Selecting content Selecting participants Preparing the cards Selecting content The first step in conducting a card sort is to determine the list of topics. This list should be drawn from a wide variety of sources: existing online content descriptions of business groups and processes planned applications and processes potential future content By including potential future content it becomes possible to create a structure that not only works now, but also will work for future content and functionality. Adding new items in the future should require minimal rework if the structure is designed correctly. Granularity and sampling content. Content selected for the cards can be individual pages, functionality, small groups of pages, or whole sections of the site. Be consistent with your chosen granularity — participants will find it difficult to group content at different levels of granularity. If you choose to use small groups of pages or sections of the site, ensure that the groups are of items that belong together. For example, don’t include a grouping of “media releases,” as this may not suit users and their tasks (they may prefer individual media releases to be grouped with other pages of similar topic.). Instead, include some individual media releases and see what participants do with them. The content for the card sort should be representative of the site (or the part of site that you are investigating). It is important to ensure that the content has enough similarity to allow groupings to be formed. If the content chosen is too varied, participants will not be able to create natural groupings. Selecting participants Card sorting may be performed individually or in groups. Keep in mind that the exercise will be performed multiple times. So, if you’re using individuals, try and get seven to ten for a good sampling. If you’re using groups, our preferred method, five groups of three participants per group (a total of 15 participants) works best. Whether you choose to use individuals or groups, the most important aspect of selecting participants is that they come from and are representative of your user group. (If you have multiple user groups, it is important to include a representative sample from each, as they may view the information differently). Scheduling individuals can be easier than scheduling groups of participants, especially if you have individuals located remotely. However, individuals can find it difficult to sort larger numbers of cards, providing less valuable input. A benefit of group sorts is that they typically provide richer. data than individual sorts. Whereas individuals need to be prompted to “think aloud,” groups tend to discuss their decisions aloud openly. Combine this with the group’s ability to handle larger numbers of cards effectively and their tendency to walk each other through questions about content or functionality, and you have a rich data set with greater insight into users’ mental model. The number of groups needed may depend upon the size and complexity of the site or product. However, we’ve found that patterns tend to emerge within five groups. These patterns become the basis for the site or product’s information architecture. When inviting participants, it’s not necessary to tell them they’ll be performing a card sort. Instead, simply tell them they’ll be asked to perform a simple task, or exercise that will help you (re)design the site or product. Additionally, let them know they don’t need to prepare ahead of time; they should simply come as they are. Preparing the cards Each item on your list should be placed on a card. The labels you use on the cards are extremely important. They should be short enough that participants can quickly read the card, yet detailed enough that participants can understand what the content is. When necessary, the label can be supplemented with a short description or image on the back of the card. Labels may be printed on standard (Avery) mailing labels, or printed by hand. We recommend using mailing labels as this saves time and the labels will be more legible. Mark each card with a letter or number to make analysis easier once the sorting is done. You can use whatever cards you have on hand, but we recommend 3” x 5” (10cm x 15cm). Index cards are durable, easy to see from a distance, and readily available at office supply stores. You may also use Post-it® notes, but it is our experience that cards are more durable and easier to handle. Number of cards. While there is no magic number, we have found that between 30 and 100 cards works well. Fewer than 30 cards typically does not allow for enough grouping to emerge and more than 100 cards can be time consuming and tiring for participants. However, we have performed successful card sorts with over 200 cards where participants understood the content well. In addition to the labeled cards, be sure to include some blank cards in case participants need to add something. And don’t forget a pen. Execution For the purpose of this article, we will describe an ideal execution for a card sorting exercise. Keep in mind that there are several variations, as described above. The cards have been labeled using Avery labels on 3” x 5” index cards. On the back of each card is a letter/number combination, as well as a short description or image as necessary. The letter/number combination will be used during analysis; the short description or image is provided to clarify titles that might prove confusing. The cards are shuffled prior to participants entering the room. The shuffled cards, a stack of 20 blank cards, and an ink pen are placed on the table. Three participants are brought into the room and given an introduction with some basic instructions, like these: First of all, we’d like to thank you for coming. As you may be aware, we’re in the initial stages of (re)designing a (web site, product, intranet). In order to make it as easy to use as possible, we’d like to get some input from the people who will be using it. And that’s where you come in. We’re going to ask you to perform a very simple exercise that will give us some great insight into how we can make this (web site, product, intranet) easier to use. Here’s how it works. In front of you is a stack of cards. Those cards represent the content and functionality for this (web site, product, intranet). Working together, you should try and sort the cards into groups that make sense to you. Don’t worry about trying to design the navigation; we’ll take care of that. Also, don’t be concerned with trying to organize the information as it is currently organized on your (web site, product, intranet). We’re more interested in seeing how you would organize it into groups you would expect to find things in. Once your groups are established, we’d like to have you give each group a name that makes sense to you. You are allowed to make sub-groups if you feel that’s appropriate. If you feel something is missing, you can use a blank index card to add it. Additionally, if a label is unclear, feel free to write a better label on the card. Finally, if you think something doesn’t belong, you can make an “outlier” pile. Oh, and one last thing. Feel free to ask questions during the exercise if you feel the need. I can’t guarantee that I can answer them during the exercise, but I’ll do my best to answer them when you’re finished. Facilitating card sorts can be tricky. During the exercise, your main job is to observe and listen. Your secondary job is to keep the momentum going without leading the participants. Take notes on a small notepad to keep track of insightful comments made by participants, or questions that come up during the session. Try to make sure each participant has the opportunity to provide input. If one of the participants tries to “take over” the sort, gently prompt the other participants. If one participant sits back, gently prompt that participant. If the group creates a “miscellaneous” group, ask them if they are satisfied with that group, or if they would like to take another look at it to see if it needs to be sorted further. Make sure not to lead them too much. Once the sort is complete, you may see something that looks like this: Sample of card sorting exercise. Click to enlarge. Once the participants are finished, walk them through a particular task. This helps validate the results. For example, if the site has some type of account management, or profile feature, ask them to walk you through updating their address information. Analyzing the results/next steps Analyzing card sort data is part science, part magic. Analysis can be done in two ways: by looking for broad patterns in the data or by using cluster analysis software. When performing analysis on smaller numbers of cards, you may be able to see patterns by simply laying the groups out on a table, or taping them on a whiteboard. You will be able to see patterns through similar groupings and labeling. When performing analysis on larger numbers of cards, we suggest using a spreadsheet. Enter the results into a spreadsheet, making sure to capture the title and number on each card. If the participants changed the label on a card, record the new label and place the old label in parentheses. Once you’ve entered the data, begin looking for patterns across the groups. Keep in mind the discussions held between the group participants during the sort, as they provide additional insight that might not appear in the spreadsheet. At this point, you are not looking for a definitive answer, but for insights and ideas. Another technique for analyzing data can be found in “Analyzing Card Sort Results with a Spreadsheet Template”; by Joe Lamantia.. Follow the instructions in Lamantia’s article to prepare the spreadsheet. As he mentions, look at the results for high-agreement cards and low agreement cards. In both types of analysis, patterns will emerge. These patterns will likely be sensible for the actual users. It is important to note that areas of difference also provide useful insights. Areas of difference tell us about: content that participants haven’t understood well content that could belong to more than one area alternative paths to content (for example, a list of all “how-to” articles could be created) how different types of participants see information There definitely is some magic in the analysis step, and it is difficult to provide exact instructions on what to look for. Allow yourself some time to explore more than one organizational model based on the information provided from your analysis. Remember that it is not necessary to jump straight to a taxonomy at this point. Your card sort results can be supplemented with additional user research and task analysis. Issues/Variations. There are a range of additional tasks that you can ask participants to do during the exercise, including these: Home page content: ask participants to put to one side content that they would use so often that they would want a link on the home page to it. Information- seeking task: after the exercise, bundle up the piles of cards on the table so only the top level is showing. Ask participants where they put particular content. (It is worth doing this if you suspect that the participants were not thinking about how they would use the content as they sorted) The resulting draft information architecture can be evaluated using Donna’s card-based classification evaluation. This technique provides additional information about the grouping of the content, as it focuses on tasks that users would do rather than just focusing on content. Frequently, participants will create groupings of content in a card sort that they then cannot use when asked to perform a scenario. Summary In summary, card sorting is a simple, reliable, and inexpensive method for gathering user input for an overall structure. It is most effective in the early stages of a (re)design. And while it’s not intended to be a silver bullet, when done correctly, it is instrumental in capturing helpful information to answer questions during the information design phase – ultimately making the product easier to use. Invitation One reason we wanted to write this article was to get a detailed explanation of card sorting in one place. Please expand this article into a definitive card sorting resource by adding comments with your own variations or observations. (Comment on this)
10:43 pm	Value-Driven Intranet Design Within most corporations, taking ownership of an intranet is an unglamorous, exhausting, and thankless job for a new intranet manager. Many corporate intranets lack thoughtful, focused, and disciplined design and are often extremely large and unwieldy. Fixing these intranets can seem an impossible and futile task. ----- Fundamentally, your intranet must be tied to value creation like other business services within your organization. ----- Furthermore, with new terminology proliferating from the armies of IT consultants, software vendors and business professors in the marketplace, it is becoming even harder to define an intranet, determine what it should accomplish, and measure those accomplishments. In the domain of company intranets, terms like empty portals, peer-to-peer sharing, smart enterprises, digital dashboards, social networks, taxonomy design, and knowledge management all come together and compete for attention and dollars. These buzzwords capture the imagination of senior executives who force you to devote dollars to intranet-related initiatives that the organization may not be ready for or that do not benefit the employee community. Managing these internal and external challenges and developing your intranet into a meaningful, measurable, and relevant business tool can be difficult and draining. But if you reduce your intranet to its essence, use consultants smartly, manage your stakeholders and users effectively, and approach it with the same rigor, discipline, and focus you do with any other business initiative, your task can quickly become much simpler. Defining the intranet’s value Fundamentally, your intranet must be tied to value creation like other business services within your organization. If it does not result in value creation for your business, the intranet is a failed service. Establishing value creation can be tricky. Intranet objectives such as increased employee communication, collaboration, and knowledge management are hard to quantify and measure. As a result, some corporations choose to establish tactile goals in the form of metrics such as page views, total hits, and customer satisfaction ratings. This approach is not effective for understanding and measuring the value creation driven through your intranet. Measuring the value is difficult, as the intranet’s greatest benefits to an organization are not in a measurable, packaged, and corporeal form. So how do you determine the value of an intranet? A recent MIT Sloan Management Review article by C.K. Prahalad and Venkatram Ramaswamy introduces an approach to understanding value creation, which can be applied to understanding an intranet’s value as well. Prahalad and Ramaswamy discuss how value is increasingly being defined through the co-creation of experiences in which the consumer (in this case, the employee) triggers value creation through the combination of a personal event-based need and the actual services being provided. The nature of the individual’s involvement, the personal event that leads to the interaction, and the personal meaning derived from the interaction are what determine the value creation. This theory applies to the intranet domain where the intranet alone doesn’t create value, but the site’s efficient, able use in the context of specific, individual employee needs does. The use of the intranet in the context of other services provided by the organization also affects the value creation. Unlike a product or service that is sold to a consumer and therefore has an easily recognizable cost and perceived value, the use of an intranet rarely costs an employee anything. As a result, the value is not assessed at the point of purchase but rather at the point of use, and therefore is tied directly to how it is used. This approach for understanding an intranet’s value can seem to make it still harder to measure the value because the value creation happens at a personal, individualized, non-structured, and non-measurable level. Also, measuring the value of the intranet at the point of use puts the onus on the employee to create value by using the intranet more effectively. With such a definition of value creation for your intranet, can the value be measured at all? Measuring the intranet’s value In this context, breaking up your intranet into discrete, tightly defined services is the first step in measuring its value. These discrete services should provide tangible benefits to narrowly defined target audiences. They should be as self-contained as possible and ideally should be designed, positioned, and perceived as co-services in the context of other services provided in the offline space to the target audiences. Let’s take the case of sales information in a drug company to explore this point. Intranets are commonly used as platforms to distribute market share and sales information to field sales representatives. The effective and efficient dissemination of timely sales information segmented by product and region is, in this example, the means for determining the value creation. In this case, the business objective is to share the sales information. This objective can be divided into a series of discrete services by information type, namely the broadcasting of general market share information by brand and region; market-specific sales and competitor trends to representatives in a particular region; and finally real time, sales-representative-specific raw sales data that is used to motivate each sales person and communicate progress towards individual monthly targets. The next step is to take one of these services—for example, the communication of sales-representative-specific sales data—and ask yourself and the specific target audience questions such as: Is this service being delivered in the offline space? If so, how effectively is it being delivered and is it reaching all of its target audience? Can the service be delivered more effectively and efficiently via the intranet? Will it reach a larger percentage of the target audience? Will the offline service need to continue once the intranet service is launched? How does the target audience benefit from access to the service? Under what circumstances will they use this service? Does it make a meaningful difference to their jobs? Does it enable them to create measurable value for the company? Do they have the right tools, usage patterns, and motivations to use the service? The questions above are designed to help you truly understand the need for the service, the context in which the service will be used, the tie to the business value through the service, and the personal event triggers that will motivate use of the service. Without looking at each of these elements in the context of each service piece on your intranet, it will be hard to determine value creation and prioritize future enhancements. As you go through the exercise above of dividing your intranet into discrete services and determining how they create value for the organization, you will quickly uncover certain trends that are commonly seen across large corporate intranets. These trends include: Value creation is optimized around a small set of high-value core services, which provide dependable value to tightly defined target audiences. These high-value core services are not expensive to deliver and manage. Their success lies in their recognition of basic employee needs and the simplicity with which they respond to those needs. High-value core services share similarities in how they serve their audiences, the personal events that trigger their uses, and the methods of generating value through their use. This is because these services are most in tune with the organizational behavior and culture of the organization and fit neatly into that modus operandi. Services with extremely narrowly defined audiences based in one location are less successful, as offline and unstructured mechanisms for communication, collaboration, knowledge management, and task performance needs take precedence. There’s often a direction correlation between the size of your target audiences, how geographically dispersed they are, and the value of a particular service. Similarly, services that have carelessly defined target audiences fail because the broader and more loosely defined the target audience, the more challenging it is to identify common personal event triggers and design a service to meaningfully respond to those triggers. When you complete the exercise of identifying the high-value core services—i.e., the services on your intranet that result in the greatest value creation for the organization at the least cost—you will discover how your intranet is currently being perceived and valued. If your intranet is not providing much value, it is a sign either that there’s lots of room for improvement or that other tools and processes within your organization are serving your employee needs effectively enough. Managing and nurturing talent Once you have determined where your intranet’s value lies, the next questions are what should it do for your organization, and how do you create optimal environments for value creation. This is where two fundamental business drivers come into play: managing your talent pool and listening very closely to your customers. Managing and nurturing talent is always challenging, and it becomes even harder when providing a technological service to an internal clientele. How do you identify the right resources to deliver on the promise of your intranet? How do you find them in the first place? Do they reside within your organization or do you have to bring in consultants enmasse to do the job for you? What about knowledge transfer and providing exciting growth opportunities for your team once the core set of intranet services has been built? The following steps can help you manage your talent pool more effectively. Identify an intranet solutions strategist. The strategist is an individual who intuitively understands the potential of your intranet as well as the limits of what it can cost-effectively accomplish from a business perspective. This person needs to have enough intranet design experience, preferably in other organizations, to be able to quickly grasp the current state of the intranet, identify the key areas to focus on for improvement, and bring in the right skills to execute on the creation of new services and the redesign of existing ones. The intranet solutions strategist needs to have seen it all before, and should ideally also have experience in project execution and the management of interdisciplinary teams. This person can either be an employee or a consultant. Organize your teams by services delivered rather than skill silos. Interdisciplinary teams are recognized as being more cost-effective and more likely to deliver on-time and on-budget services. Each service team should have the use of the intranet solutions strategist’s time for guiding the design and development of their core services. Roles and responsibilities should be determined in a similar fashion to those defined for the cell teams that are common in manufacturing plants. Cell teams closely locate people and equipment required for certain processing families of like products. The cell’s operators are often cross-trained on several tasks, engage in job rotation, and take more ownership and responsibility than in normal manufacturing plants. Similarly, your intranet service teams must share a common value system, work practices and means of communication. A certain degree of creative dissonance should be tolerated but nevertheless controlled. Establish measurable objectives for these teams. These teams should be given core services to develop or redevelop within specified timeframes. They should be financially motivated for timely delivery, cost control, and customer acceptance. The teams should always have visibility into the work that will follow the delivery of their current project. Creating an atmosphere of professional competitiveness between teams can serve as a motivator, especially if the teams have financial incentives. Leverage teams across all web properties. Your intranet teams should not be confined to intranet design but should be given opportunities to take on the design and development of services related to external website and extranet projects. The philosophies that drive strong intranet design whether in the business analysis, user experience, or technology sphere are just as applicable to other web initiatives. Encourage and reward cross-pollination with other business units. If you manage an intranet in a large organization, encourage other departments to borrow your more junior employees for short periods. The experience in the business will be rewarding for the team members, and it will bring fresh insights into intranet usage patterns, strategies, and tactics for new services that benefit the business and exposure to business processes. Likewise, bringing in employees from the business for short periods will give your teams new insights into the business and how to optimize the intranet around use. Unlike an external web solution, you have the benefit of having your customers work for your CEO just as you do. This provides incredible opportunities for understanding and serving them better — short-term cross-pollination is one such opportunity that should not be missed. Usually the best person to play the intranet solutions strategist role is an external consultant, as you want someone with diverse experience. Using consultants effectively As you have probably observed, the team structures recommended above share many similarities to the way consultancies are organized. This is because consultancies are tightly focused on delivery and cost control. So do you need consultants at all, and if so, how do you use them? This is where things can get a little trickier. Usually the best person to play the intranet solutions strategist role is an external consultant, as you want someone with diverse experience. This consultant would naturally rather lead his or her own teams than have to shepherd internal employees. Often that can be a condition for a consultant accepting such a position. So how do you resolve this dilemma? The answer is to either combine your teams with the consultant’s team (which the external firm will resist, arguing that there are increased delivery and quality risks involved in mixing teams), or to bring in the consulting firm to deliver certain services while having your internal team develop other services. In the situation presented above, it is much easier to engage with the consulting firm and leverage the intranet solutions strategist across all the teams. The goal should be to engage with the intranet solutions strategist on a near-permanent basis and bring in consulting teams occasionally to augment your internal talent pool. What if you do not have the right type of talent in-house? The answer is to invest in training and hiring as soon as you can. Using consultants to solve your talent shortages is an expensive solution, and while it will produce the quick short-term results that you may need to deliver, in the long term it will turn out to be much more expensive. The only exception to this rule is if you find that your intranet initiatives are not complex enough or continuous to warrant full time internal teams. Listening to your customers The importance of listening to your customers in business can never be underemphasized, and it matters just as much in the intranet domain. Ironically, because your customers are so close to you, you might be in a situation where you believe that you are listening to them when you actually aren’t. Inter-department politics and clashes over annual budgets make it hard to listen to what the business community is saying versus what you’d like them to be saying. The following steps can help you listen better: Organize yourself into a result-oriented governance model that includes representation from your business community. These representatives should be able to commit at least ten hours each month to prioritize services, support usability testing, and serve as champions for new services rolled out. Do not depend on them for anything else. You might be accused of taking more of their time than you should and, worse still, inviting them to make decisions in areas that they shouldn’t. Making all intranet-related documentation available to them should greatly mitigate the concerns regarding involvement that they may have. Set up a usability laboratory for monthly testing. Usability labs are extremely cheap to set up and manage and they provide immense benefits to your intranet teams. Require monthly usability testing of new or redesigned services; this will put pressure on your intranet teams to deliver something each month, and it will keep your user community involved. Publish the results of these tests for all your intranet teams and the larger business community. Rotate which user representatives get to participate in the usability testing. Invite senior executives and your business representatives to watch the testing so that they understand the challenges of intranet design. Design and deploy for use. Engage with your business community as actively as possible for the design and rollout of a particular service. Make them feel like you are providing them a service and that they are your client. Listen and understand the business needs, and map these processes on paper before designing a digital solution. Promote transparency and engage with them to provide feedback at critical stages. Be careful not to include them to such an extent that your design process evolves into participatory design. The business owners are not your intranet designers; they are your users, and just as car manufacturers regularly bring in customers to view prototypes but refuse to let them participate in the actual design process, so should you limit the participation of your business users. This needs to be done tactfully; these representatives need to be your champions, so you don’t want to disenfranchise them. There’s an axiom in the business community that if you want your boss to like your decisions, let him or her make them for you. Don’t fall victim to that axiom. Always question the value creation. Demonstrate to the business community how your intranet is broken into a series of services with core audiences to whom you provide measurable value. Encourage them to think of new services for additional value creation. Keep them updated on releases, delays, and plans for future services. Don’t be afraid to scrap projects midway through if you discover they will not provide sufficient value. While this may hurt you in the short term, as your detractors will consider it a failure, in the long term it will establish greater credibility. Conclusion Too often, large corporations approach intranet design like any other technological initiative. You have your end users. You have the technology, an interface, and the usual parameters of cost, time, build-versus-buy decision making, resourcing, and interoperability with other technology. But intranet design is not just another technology initiative. Rather, it is a targeted business service to employees within your organization. Greater emphasis should be put on the strategy and the design and less on the technological implementation. An intranet’s value should never be determined by what technology it uses, how quickly it is rolled out, or how many standards it complies with. Keep this in mind as you design your intranet, establish where value creation lies, and engage with your customers. Also remember that the value of your intranet might be hidden and not immediately apparent. If designed appropriately, your intranet can provide immense value to your employee base. This was seen in a Watson Wyatt HCI study, which revealed that implementing technologies that improve employee service can increase shareholder value by as much as 2.3 percent (Watson Wyatt’s 2001 Human Capital Index® [HCI] study). This means that organizations can generate an additional 2.3 percent increase in shareholder value by using employee relationship solutions to reduce the costs associated with delivering service to employees. This is not a percentage to ignore. Fixing an intranet can be likened to trying to repair a submarine while at sea. Your customers will continue to have needs for new services and functionality while you try to fix the existing problems. But by identifying where the true value of your intranet lies, managing your talent pool effectively, and engaging with your business community strategically, you will be able to align your customers with your vision of the intranet, meet their most important needs, and fix the right services at the same time. (Comment on this)
10:42 pm	Extending a Technique: Group Personas 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. ----- Spock: “The needs of the many outweigh the needs of the few.” Kirk: “Or the one.” —Star Trek II: Wrath of Khan ----- 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. We first sketched out some personas, and that went fine. But once we began working with scenarios for a while, trying to create believable situations for these characters to behave in, we noticed something: all of our scenarios consisted of groups of personas interacting with the environment or with other groups of personas. That’s when we realized that individuals mostly don’t act alone in amusement parks. People rarely go alone and they don’t make decisions alone. Needs and desires are negotiated in a group, not expressed individually. People really fully embrace the experience only when they’re experiencing it with others. In this environment, individual personas and scenarios for them matter less than what happens to groups of people. So we decided to see if we could make group personas. At first, there was some apprehension—what if the groups are so varied as to be impossible to characterize? But as soon as we started making them, only several different kinds of personas made sense and it became a straightforward extension of Alan Cooper’s original persona technique. Here’s how we did it. Individual descriptions We had started by describing individual personas, so we had the building blocks of groups, and we used those personas as the basis of our subsequent work. Those personas were based on several visitor categories that we defined based on the park’s operators’ knowledge of their audience—the statistics they had and their personal experience with the park: Teenagers Young adults Pre-teens Young parents Grandparents We decided to leave the profiles broad, rather than going into detailed persona building, and described each group along some criteria appropriate to the problems the park was trying to solve. Young parents, for example were described thus: Age: 25-35 Children: 2 Budget: $75-100 per day (in the park, not including tickets) per parent Technology: cell phone (6-24 months old), digital camera, video camera, computer at home, internet connectivity in the office Desires: have fun with kids, let kids run around in safe place Needs: to have fun, too; place to change diapers; place to sit down; to buy food/drink Of course, this only scratches the surface of how young parents in an amusement park can be described—we could have defined different criteria based on gender, culture (this park has sizable populations of visitors from as far as Poland), etc.—but time was limited and it was enough to get us started creating group personas. Rough outlines Before fleshing out the group personas, we decided to make some rough outlines of the clusters of people one might find in the park. Based on what we had heard from the park staff and additional interviews we conducted with a couple of friends-of-friends who had visited the park as tourists, we came up with four different groups to focus on, and tried to give them distinctive names: The Teen Posse Young Parents, Young Kids The Extended Family College-age Friends We also defined some axes along which we could define the group. Again, we chose to pick out those qualities that we felt would be valuable in answering the park’s questions, rather than trying to describe every detail. Thus, the “Young Parents, Young Kids” general description looked like this: Number of people in group: 5 People in group: 2 adults, 2 kids ages 3-10, grandparent Time spent in park per day: 6 hours Number of days visiting park: 2 Season: August The level of detail at this stage needed to emphasize the group as a whole and make it different from the other groups, without burdening it (and ourselves) with descriptions that didn’t affect the end experience. We didn’t describe the individual members of the group, and included as few constraining specifics as possible. Such details and idiosyncrasies would come in the persona, which we did next. Iterative persona creation We developed each persona in several passes, both to refine the persona until it had sufficient believability and because this was the first time any of us had developed group personas, so we naturally ended up over-describing certain aspects and under-describing others. The process was roughly as follows: a rough sketch, where we quickly outlined the persona, determining its composition and adding some defining details a detail brainstorm, where we added as many details as we could, even if they were silly, contradictory or redundant editing, where we cut out everything we thought was irrelevant to addressing the project focus, and clarified overlapping ideas preliminary scenario writing, during which we “exercised” the personas by walking them through some examples in which they interacted with the park and some of the design ideas on the table tuning, where we adjusted the personas based on what we had learned from the scenarios After a couple of days of doing this for 2-3 hours per group persona, we had four fleshed-out group personas and some scenarios that we felt were typical examples of groups who visited the park and how they would behave. These we used to examine the problems the park was experiencing and our proposed solutions. Example: The Ancona Family, a secondary persona Note: this persona is significantly modified from what we developed in the workshop. Back story Luisa and Giorgio, a couple in their mid-30s, have decided that the family needs a vacation. It’s mid-August and they’re spending time with Luisa’s parents, Maria and Carlo, at their home outside of Rome. Mauricio and Laura, their children, are getting bored and cranky and clearly need a break from hanging out at the grandparents’ house. Giorgio suggests they spend a weekend at an amusement park with water rides before they go to Rimini for the traditional week on the beach. Maria, Luisa’s mother, will come along. She’s always willing to help out with the kids. Demographics Luisa and Giorgio are in their mid-30s. They live in Rome. They’ve been married for five years. Giorgio is a mechanical engineer and Luisa is a full-time parent and also works part-time at her parents’ grocery store. Mauricio and Laura are their 7- and 4-year-old children. Maria is Luisa’s mother. She is in her late 50s. She lives outside of Rome with her husband, Carlo. They own a small grocery store, where Maria manages, in addition to being a full-time homemaker. Technology use The park was interested in developing wearable or portable technology for people to use as they’re being entertained, so we included a range of technologies in our description, rather than just focusing on computer and software experience, as we would have if this was a piece of software or a website. Luisa and Giorgio have mobile phones. They’re very comfortable sending text messages, and typically send 3-5 to each other per day. Luisa sometimes uses hers to play video games and she texts one of her friends almost every day. Luisa’s phone is newer than Giorgio’s and has a camera. They have a two-year-old computer at home, which Giorgio and Luisa use to send email (they have a dialup internet account) and which the kids use to play video games and watch DVDs. Giorgio has a faster internet connection at his office. They have a digital video camera with them, which Luisa bought for Giorgio for his last birthday. Maria doesn’t have a mobile phone, but she’s comfortable using one. Luisa and Giorgio have taught Mauricio how to call the emergency number on a mobile phone, but he’s otherwise not used one even though he understands in principle how they work. Goals Group goals are a negotiated combination of individual goals. In a family trip, most of the long-term goals are set by the parents, and most of the short-term goals are set by the kids. Mauricio has one major goal: to ride the big roller coaster over and over again. He’s never been on one, but he knows about it. He’s also very interested in the dinosaur area. Laura has never been to an amusement park before, so she doesn’t know what to expect, but her parents told her about the costumed mascots and water rides and she’s excited to see those. Giorgio: Have fun with his kids Wants to use his new video camera Wants to ride the roller coaster Luisa: Wants to spend time with Giorgio and her kids Wants to ride the ferris wheel Maria: Talk to her daughter Spend time with her grandchildren Combining these, we get a set of general goals: Ride the big roller coaster Avoid boredom Spend time together Needs In our example, goals are individual but they affect the whole group, whereas needs are mostly group-wide. This may be a product of our process, or it may point to a general case of how group personas work. Find each other Find the bathroom Be entertained while waiting in line Get food/water Rest for Maria, while kids are being entertained Purchasing profile Since selling stuff is a key amusement park revenue stream, we decided to do a short profile of what the group is likely to purchase throughout the day. Ice cream, bought by Maria, as a treat for the kids Soda in a theme cup, requested by Laura, bought by Giorgio Lunch for everyone, bought by Luisa and Giorgio Disposable camera bought by Luisa Sunscreen, bought by Luisa T-shirts for Mauricio and Laura, bought by Giorgio Example: Ancona family scenarios Having developed a general group persona, the next step was to develop some scenarios using the persona in order to test it and further refine it. Day narrative We began with a general narrative of what happens during the day. Here’s an abbreviated version of the first day: 6:00 AM: kids wake up 8:00 AM: breakfast at Maria and Carlo’s home 9:00 AM: family leaves for park 10:30 AM: arrive at hotel near park, check in 11:30 AM: leave for park 12:00 PM: arrive at park, buy tickets, go in, start getting oriented 12:30 PM: orientation chaos: where to go? what to do? Negotiation and prioritization. 12:45 PM: Giorgio and Mauricio head for roller coaster. Luisa, Laura and Maria start looking for a place where Maria can wait with Laura while Luisa joins her husband and son. 1:00 PM: Giorgio and Mauricio arrive, get in line. 1:15 PM: Luisa and Maria find picnic area where Maria can wait. 1:30 PM: Luisa joins Giorgio and Mauricio. 2:30 PM: Luisa, Giorgio and Mauricio get to the front of the line and ride the roller coaster. Everyone is very hungry. 2:45 PM: Group reunited, start looking for lunch. 3:00 PM: Lunch bought at stand near picnic area. Etc. Where are Giorgio and Laura? Using this structure, we started thinking about technological solutions: what problems are encountered? How can the information technology we know the family has or has experience with affect the situation? How can the park benefit? Business problem: People complain of getting lost when trying to reunite when groups separate. Scenario: Laura really wanted to go on the water flume ride, but since everyone gets soaked while on it, the rest of the family doesn’t really want to go. Giorgio and Luisa agree that he’ll go, while she and Mauricio and Maria go to the ferris wheel. Since everyone gets soaked, Giorgio doesn’t want to take his mobile phone and leaves it with Luisa. Now, how will they meet up again? They don’t know how long the lines at the various rides are. How will they know when to meet? If the water ride line is as long as the roller coaster and the ferris wheel has no line, then Luisa, Maria and Mauricio may end up waiting hours for Giorgio and Laura to get back. Potential solutions: Wait-time kiosks. If there are kiosks scattered around the park that tell people how long the lines at the rides are, then the family can estimate how long the whole process will take and pick a time and place to meet up again. RFID bracelets/ride check-in. Everyone gets a wrist bracelet when they buy their ticket. Assume that each bracelet has an RFID (radio frequency ID) tag in it and people’s IDs are linked Waterproof mobile phone bags. Watertight bags provided by the park for people waiting in line for water rides. These allow people to coordinate and communicate using the tools they’re familiar with. Using the group persona, we were able to explore and evaluate how well these solutions worked, both for the Anconas and for the park. The low-tech solution, the bags, is cheap and requires the minimum investment by the park in new technology and by the Anconas in learning a new system, but it’s not without problems. What if Giorgio, who’s quite attached to his phone, doesn’t trust the bag? What we learned This exercise was incredibly helpful when we started designing technology to support people’s experience in the park. Groups are not individuals, though they sometimes act like them. As the persona is developed and as scenarios are written, the focus shifts from the individuals in a group to the group as a whole. The group is rarely treated as an entity identical to an individual, but it often behaves as one. So when the Anconas move around the park, they’re often moving as a group. Where they go may be heavily influenced by one person’s desires (Mauricio’s desire to ride the big coaster), but the decision is made collectively and they act as a group. Group descriptions should have moderate detail, but not too much. While it’s not necessary to describe either the group or its members in deep detail, some description is important. In fact, describing groups as groups is actually tough: we just don’t have that many axes along which we typically describe small groups: we can number the members and collect aggregate demographic information, but that’s about it. We had to invent a lot of the categories we used on the fly. The design goal drives the persona description. Remembering that this was an amusement park and that we were going to be designing ways in which the park could support and encourage the use of personal technology really helped focus the persona development process. It narrowed the directions we explored and how we spent our time fleshing out ideas. There were times when we’d go too far into describing the persona and clearly enjoying the storytelling aspect too much, which was fine and often useful, but then the design goal allowed us to edit what we had produced so that it was most relevant. Imperfection is important. We found we had a tendency to tell stories where everything goes right and technology saves the day and makes everyone happy. Though this made us feel good, it’s not realistic, and the exercise of examining where our ideas could fail, where they could be misunderstood and misused, was quite helpful. This is a really useful tool for realistic idea generation. When given a broad mandate, this technique allowed us to narrow the space of all possible uses of technology from what was merely possible to what seemed like it would be actually useful and valuable. It defined the space in which we could create innovative ideas and to understand where services that bridged technologies made sense and where they didn’t. It also allowed us to see the problems with some of the ideas. Extending traditional techniques to groups is possible and valuable. This was the first time I tried this technique. Frankly, I kind of invented it on the spot and my workshop participants ran with it, but the process of taking a known technique and stretching it to a new set of problems proved quite valuable, both in terms of helping us solve the problems we were tasked with and in terms of understanding what I know about individual personas. Extending to other kinds of experience design. So what does all of this amusement park stuff have to do with software and websites? It’s directly applicable to software that’s used by groups. Entertainment, education, and collaboration software is often used by two or more people simultaneously (and not in the sequential “I edit this, then I give it to you to edit” model, but simultaneously). It’s difficult to imagine teleconferencing software without thinking about two groups—one at either end of the connection—using it; sometimes these are groups of executives, sometimes they’re technical collaborators, sometimes they’re mixed. Each of these different groups has a different set of needs and expectations from the software, and each can be modeled as a group persona, rather than as individual users. In the most general sense, as our tools become more social, as information processing and ubiquitous computing pervade our environment, so should our techniques to model their users. Group personas are a small and easy step. (Comment on this)
10:41 pm	Making Personas More Powerful: Details to Drive Strategic and Tactical Design 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. ----- “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.” ----- 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? 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. Cooper’s company most often dealt with enterprise clients who hadn’t yet bought into the value of user experience. As a consultant, he had a strong need to persuade internal development teams to pay attention to users, so, not surprisingly, he emphasized both the narrative and empathy-building aspects of personas. Cooper’s goals for personas were to: Allow the development team to live and breathe the user’s world. Allow the team to filter out personal quirks and focus on motivations and behaviors typical of a broad range of users, while still relating to users as individuals. These are good goals, but incomplete. Compounding the problem was that Cooper’s seminal The Inmates Are Running the Asylum talked at length about why personas were important, but didn’t provide many details about how create them. So people improvised, often with unsatisfying results. My own frustrations with personas came as I tried to apply them to a different context. While Cooper mostly worked with enterprise clients, with developers and managers who were reluctant to consider users, I’ve usually had a hand in building the sites I design, even as an outside developer and consultant. Likewise, Cooper’s clients typically were developing internal applications where efficiency was main goal, so it’s not surprising that his approach was task-focused. But as I’ve argued previously, other types of projects are predominantly information-oriented and immersion-oriented—or some mix among the three. Much of my own work has been on consumer-facing websites and interactive products where functionality was only part of the focus. When I was developing movie promotion sites, the studios obviously hoped the websites would “put butts in seats.” But people don’t visit movie promotion sites to find out where the film is playing. Nor—if they live outside Hollywood—to find out the name of the second assistant camera operator. People go to movie promotion websites to get a taste of the film. The design challenges simply weren’t the same as Cooper’s. I needed a tool not just for creating empathy and filtering out quirks, but one that could: Guide strategic decisions about a product’s focus, Enable better tactical-level design decisions, and Help make inevitable design trade-offs. In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear. Good editors constantly pose questions to the writer to force them to reach that clarity. My toolkit is built on the efforts of others from a wide variety of fields, from HCI to branding to filmmaking. To help develop more “three-dimensional” personas, the toolkit contains more than a dozen pages of questions about: Biographic, geographic, demographic, psychographic background information The business’ relationship to the persona The persona’s relationship to product and business The persona’s specific goals, needs and attitudes The persona’s specific knowledge and proficiencies The context of usage Interaction, information, sensory, emotional aspects of the user experience Accessibility issues Relationships among personas It also includes techniques for using personas to prioritize user interface components, as well as useful definitions for providing a common language to describe this prioritization. “In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear.”My focus was on a tool for design rather than a tool for persuasion, so the questions— and resulting answers—are far too detailed for those outside the design team. But they’re necessary to enable a designer to not only make better tactical level decisions, but also to think more strategically about the product’s focus and help drive the product’s definition. The toolkit covers a wide variety of situations, so you should use the questions that are most appropriate to the context of your project. Similarly, not all the questions need to be—or should be—answered at once. The toolkit is designed to be used iteratively with questions being filled in over time as they become relevant to the design issues at hand. (However, it’s still a good idea at the start of the project, or at least at the start of each project phase, to identify the questions you think you’ll want to answer, so that you can begin gathering the necessary information.) Let’s quickly review some of the basics of persona creation. When building personas, the first challenge is finding the information to build them. Obviously, it’s preferable to talk to and observe the users themselves, but that’s not always possible. In my opinion, any information is generally better than no information, and there are inevitably other sources of information. You can talk to user surrogates, such as domain experts, trainers, or immediate supervisors. There are “informants” who know about the users, such as people in the marketing, sales or customer support departments. For example, I once designed an extranet for a company’s board of directors. I couldn’t get access to the board, but their support staff was able to tell me all I needed about the directors’ behavior and computer skills. There are other indirect sources as well, such as manuals (especially those with notes written in them), site logs, customer feedback forms, surveys, etc. But one indirect source to be wary of is “ersatz” users—most commonly upper-level executives who think they understand their customers far more than they typically do. After gathering information, I prioritize personas into the following types: Focal—These are the primary users who are the product’s target. Secondary—They also use the product and we’ll satisfy them when we can. But their needs can be sacrificed to meet the needs of focal users. Unimportant—Infrequent, unauthorized, or otherwise low-priority users. Affected—They don’t use the product but are affected by it. For example, one member of the family may do the research when buying a car, but the others—who are usually involved in the decision—will be affected by that person’s work. Exclusionary—We’re not designing for them. Period. Stakeholders—I’ve often found it useful to create mini-personas that represent their interests and involvement. These can range from advertisers to senior management to industry influencers to regulatory agencies. Stakeholders may—or may not—be something you want to put into writing. But stakeholder personas are often useful to formally create because they provide a good way of ensuring stakeholder issues get discussed openly. If you’re including a feature solely because it will get press coverage, it’s better to acknowledge this in the design process than to pretend that it’s there to satisfy a user need. You probably want no more than a dozen personas, with at least one focal persona. But if there are more than three focal personas, you’re trying to do too much, and you need to subdivide the product or interface—for example, separating the “user’s” user interface from the “administrator’s” user interface. This is probably familiar ground. But I mention it because it’s critical to get team consensus on the relative priority of each persona in order to later prioritize specific design decisions. What is your persona’s background? At the broadest level, persona development starts with the biographic background, including: Geographic profile. Where do your personas live and work? What’s it like there? Why can this matter? It’s worth noting that some of the earliest non-U.S. internet adopters were the Scandinavian countries, Australia, and New Zealand. While geography may not be destiny, I suspect the rapid adoption was in part due to the long dark winters of the former and the geographical isolation of the latter. Demographic profile, such as age, gender, family size, income, occupation, education, etc., information that’s available from the marketing team. It’s frequently less useful for understanding the behavioral aspects of your persona, but can useful in rounding out a persona’s character. Politically, it’s a good way to get Marketing to buy in. Psychographics, which include social class, lifestyle traits and motivations, personality characteristics and attitudes. These can be important in understanding the proper tone and voice to give a product. For example, the PRIZM system developed by Claritas—based on the idea that people with similar tastes tend to live in the same neighborhoods—is eerily accurate in describing people’s likely interests based on their ZIP code (You can try it yourself here.) I’ve also found it to be a useful tool for adding in non-essential details that make personas feel more realistic. What’s the relationship between persona, product and business? Some of the key strategic questions are around the persona’s relationship with—and value to—the business. Is the persona a customer, an employee, a partner? A company will likely want to communicate different messages for its external sites than its intranet. An extranet may display different content for a preferred vendor than for other vendors. Similarly, a website might restrict certain information to only paying customers, while leaving other content available to all users. Conversely, what sort of relationship does your persona have with your product or business? Are they a heavy user or a non-user? If you’re trying to acquire customers from a competing product, then you need to understand the people who aren’t using your product. What’s your persona’s attitude toward your product, your brand and your company? What kind of relationship would your persona like to have—but doesn’t have now? Enterprise applications are often like arranged marriages—employees use them not out of love, but because they’ve been told to do so. Linux users have an undying “hate affair” with all things Microsoft, and Tivo users will tell you that it changed their lives. Where’s the relationship headed? If you’re MTV, you’d best recognize that your brand relationship is a passing fling; in a few years, today’s viewers will be wearing Dockers and watching VH-1. In contrast, you’d have to pry their Macs out of the cold, dead hands of many users with a lifelong commitment to Apple. What’s the persona’s value to the business? More zealous advocates of user-centered design seem to think any user is valuable, but that simply isn’t true. The 80/20 rule was discovered by an economist’s extensive analysis of businesses that discovered 20 percent of customers did account to 80 percent of revenues. It can be useful to think about what percentage of overall users (or overall revenue) a persona represents. It may not the critical factor in a persona’s priority, but if nothing else prepares you to answer questions from the business side of the project. What’s the context around the product’s usage? Focusing on the product being offered, what are the specific goals, needs and attitudes surrounding the context in which your personas will use the product? Crown Equipment Corporation realized that even warehouse workers want to be “cool,” which was the inspiration for the stylish exterior of its Wave rolling ladder replacement. The product has been a hit. Not only did it create significant jumps in efficiency because it allows one person to do the job of two, but companies using it saw big increases in job satisfaction and morale. After thinking about what your personas are trying to accomplish, then look at what specific knowledge and proficiencies your personas have related to achieving that goal. A safe rule of thumb is that most users never pass the “advanced beginner” stage of expertise—nor do they really want to. This question also applies to more fundamental issues than computer skills. For example, there’s a company that provided computer-based HR training (sexual harassment policies, etc.) to hotel maids. Not all the maids spoke English, nor were all of them literate in their native languages. Needless to say, their language skills had a significant affect on the design. It’s useful to get specific about the context in which the persona is using your product. For example: When and where do users perform a task? With whom? What’s the surrounding environment? Global navigation positioning systems for sailing are used at any hour of the day or night, in any weather condition. Are there device constraints? For example, designing for a mobile phone. Are there confidentiality needs? Accuracy needs? Audit needs? What are the operational and/or safety risks? Designing a hospital billing system has big risks—but far smaller than designing the hospital’s pill-dispensing system. Is there assistance and training available? Many of us work on websites where training is impractical, but in designing an air traffic control system it may be preferable to prioritize other concerns over learnability, since the users will be formally trained in its use. Are there legal and/or regulatory restrictions? If you’ve ever worked in financial services or other regulatory industries, you know how much these issues can affect the design. What does the interaction look like? Now that we’ve looked at the context around your persona’s usage of the product, let’s take a close look at the interaction with the product itself. How frequently does the interaction take place? Is it on a regular basis? Is it continuous or interrupted? Is it so intense that it requires the persona’s full attention, or is one of several interactions that your persona is doing at once? How quickly must the persona act? How complex and how predictable is the action? Who’s driving the interaction—your personas or outside factors? If you’re designing an air traffic control system, the interactions are highly complex, but generally predictable. The controllers are the ones driving the interaction with the pilots, but it involves continuous high-intensity focus with split-second reactions for hours on end. That’s a little different than the interaction with your average website. Admittedly, these questions overlap with task analysis, but answering them for each persona can help identify important similarities and/or differences in behavior among your personas. What information is involved? Many interactions also involve information—something that traditional task analysis can overlook in its focus on actions. So the next step is to look specifically at the characteristics of the information that your persona needs and/or manipulates as part of the interaction with the product. For example, at one extreme are call centers, where the operators are listening and talking with customers, while simultaneously reading and typing on their computer screens. If you were designing the call center’s software, you’d want to think about the volume and complexity of the information being used, how it flows to and from the operators, and what level of detail is needed at what times. What makes the user experience memorable? While interaction and informational aspects of user experience can be analyzed logically, the sensory and immersive characteristics of a user experience are inherently more subjective—but no less important. Products can survive in the marketplace initially despite being crude, ugly or dangerous if they provide enough value. But over time, as competitors match quality, style becomes the differentiator. (Or price—but only one product can ever be the lowest-priced.) What’s the mood or feeling, style or genre that’s appealing to your persona? What’s appealing? What’s pleasurable? What’s memorable? Geek Squad—a boutique high-end computer-support company—is the master of the memorable experience. Does its black-and-white “Geekmobiles” and Men In Black-meets-computer nerd schtick affect the actual technical troubleshooting skills of its services? Nope. Does it make an impression? You bet. So much so that the company amassed a celebrity client list and was subsequently acquired by Best Buy, who is now launching the service in all its stores. The Geek Squad experience was no accident. It was consciously created to overcome people’s adverse reactions to arrogant tech support workers. Not surprisingly, brand researchers have paid much attention to the emotional aspects of an experience. One researcher argues that aspects of five major personality characteristics: Sincerity Excitement Competence Sophistication Ruggedness account for roughly 90 percent of brand differentiation. Regardless of whether the list is as specifically effective as claimed, it is worth thinking about what personality your product conveys and whether it’s something that’s attractive to your personas. Likewise, what is your personas’ perceived experience of using your product? Does the product convey: Sense of adventure? Feeling of independence? Sense of security? Sensuality? Confidence? Power? Strengths in many of these areas are what prompt Harley-Davidson’s customers to literally brand themselves with tattoos and jackets—and what kept the company afloat during the 1970s when the motorcycles themselves suffered severe quality problems. With this level of detail in your personas, it becomes far easier to prioritize them. The toolkit provides three approaches for doing so. This approach seems to pose numerous questions—and it does. As I mentioned previously, you only need to answer the ones that are most relevant, and not all at once. But it’s the details that will make your personas powerful. (1 Comment |Comment on this)
10:39 pm	Architecting Our Profession I would like to encourage the community to talk about the need for professional networks within the information architecture field, especially as it relates to creating successful software and information systems. And, I would like to compare our needs in the field of IA with the systems that have been used in other areas to determine if we can develop an appropriate support system in moving towards specialization in our profession. The change within the interface design process over the past five to ten years has coincided with an increasing number of large companies refining an industrial style model of design instead of focusing on specialization or interaction sustainability through design accuracy. As a result of the overriding strategy, many smaller companies emulate the corporate model but find that it is indeed not sustainable; especially if they want to design appropriate interfaces and continue working within the respected boutique and agency models. This model of simply acquiring a larger IA strategy needs to change in order to give IA a place on the whole market and to allow professional networks to develop. ----- “…there is definitely not enough reliance on the information architect as a professional who can cope with the details and design challenges of creating a complex system, both for the process and for the interface.” ----- For instance, Company A has created a large international software application, which meets the needs of very specific market segments; the application actually has to be in a boat on the other side of the world and represented in a different language. Meanwhile, Boutique A has a very similar model of designing applications, not because it’s practical for them but because “that’s the way it’s done elsewhere.” However, the boutique only provides design, technical support and some software customization to existing customers who are within a 100-kilometer radius! This is sort of like comparing apples to oranges, but it’s more like encouraging apples to grow on orange trees. It’s attempting to implement a model of business where introducing a scaled down process leads to ineffective results. This is the real hiccup in the current User Centered Design and Information Architecture processes; they are not really all that scaleable. Company A is driven by forces that Boutique A doesn’t need. Boutique A is a professional service firm in its own right, but it doesn’t need to work within such a large-scale model, especially not simply because of excess field pressure. In fact, customers would most likely benefit if the models were reversed as Company A typically avoids the simplicity of providing a local service like the one offered by Boutique A. In my experience, this is the reason that projects fail in information architecture and interaction design: it seems that many companies and individuals are not insuring that they use a process which suits them. There is not enough rationing of responsibility to contractors, and therefore no appropriate delegation to specialists who can develop an appropriate model of IA for each situation. This means that there is definitely not enough reliance on the information architect as a professional who can cope with the details and design challenges of creating a complex system, both for the process and for the interface. This is the main reason IAs are unable to blueprint systems that survive the passing of time or the pressures of an evolving market, in other words, there is a round-peg in a square-hole problem here which needs to be addressed. As IAs, we aren’t playing the role of architect, artist, or even of the contractor, but the role of design team member, using common techniques on specialized problems. Where do we find the solution? It’s likely in needs of smaller businesses and organizations. In order to make the needed room for these areas to influence the field of information architecture; we need for them to rely on or to develop their own specialists and contractors, individuals who are professionals with the insight and experience to understand the entire project, and to create new models of IA for each project. What we are missing however, is the support system to protect, establish and promote those who chose to contract out specialist needs. In order to establish this sort of specialist and contractor system, we should understand what has worked this way in other industries, especially those that rely heavily on interactive technology, such as TV, film, music as well as video game and software development. These industries all have contractor associations and specialist houses, both of which translate well to the IT industry. In our market, business needs shift and product releases are quite sporadic, and so contracting associations and specialist houses, or firms or studios, could be the answer to providing IA services that actually reflect the needs of each project. We need a system within IA where individual professionals are given the authority to examine specific elements, attributes, and functions of a system as well as to architect the process involved. In essence, this would be the IA equivalent of hiring a director, or a sound engineer, or if we think about things a bit more pragmatically, contracting an architect. This is all just a suggestion, though perhaps we should look at other models more closely in order to simplify IA processes. It is possibly the professional equivalent of giving ourselves a system for us after all these years spent figuring out what specializations to focus on. We do have the answers; all we need to do is create the infrastructure to begin to work in this way. I suggest we look at a range of options for moving forward, with such possibilities as determining a board of local association members, establishing a union system and stewards, forming an open licensing system, or just seeking out legal specialists who can represent individuals and know the field well. We should begin to entrust our efforts to people dedicated to creating support systems within the field of IA. How we should go about structuring these support systems is something else entirely; it is something that we should discuss and determine together, moving towards making a professional field. Any comments? Conclusion: Design is a valued industry in many fields, with professional support systems to match. Without adequate support systems in IA we will be awkwardly bound to the current design process out of fear of improvement. The nature of software design should be integrated and brought into the design process in a much more sustainable way, and I see support systems as the only way to provide the stability needed to develop through specialization. I’ve included a few links below; topics I consider appropriate grounding for considering specialization support within IA. Please be aware that the topic of blueprinting is only one example area where techniques and models need to be supported. The following links are given as encouragement for discussion. (Comment on this)
Thursday, August 14th, 2003
3:57 pm	дураки, всё ведь не так должно делаться (2 Comments |Comment on this)
3:55 pm	организаторы клоунады облажались (Comment on this)
Tuesday, October 8th, 2002
9:21 pm	note 001 [такой стиль...] такой стиль жизни называется «депрессия» (1 Comment |Comment on this)
Monday, October 7th, 2002
9:31 pm	recursion 001 [сначала ты заходишь] Сначала ты заходишь в парадную дверь этого дома и оказываешься в полутемном холле. Тихо. Ты идешь к лестнице, поднимаешься по ступенькам на второй этаж. Там длинный коридор с зеркалами на стенах. Старые зеркала в деревянных рамах, зеркала без рам, треснутые зеркала и зеркала целые, зеркала овальные и прямоугольные. Десятки зеркал, смотрящих одно в другое. Зеркальные туннели, у которых нет конца, туннели, уходящие в бесконечность. Сколько повидали эти зеркала на своем веку! А сколько им еще предстоит увидеть… Эти туннели помнят всё. Они запомнят и тебя. В коридоре темно. Ты зажигаешь свечу, и в зеркальных туннелях отражаются тысячи маленьких огоньков. Ты идешь по коридору. Пламя колеблется от твоего дыхания. Мерцают свечи. Бесконечно много язычков пламени в каждом зеркале. Бесконечно много тебя. Каждый — со свечей. Каждый идет по узкому коридору, не останавливаясь, не оглядываясь. Вот коридор поворачивает, и ты оказываешься в темной библиотеке. Со свечей в руках ты идешь вдоль полок. Ты ищешь книгу. Она тут есть — это точно. Тут есть все книги, просто нужно хорошо поискать. Ты ищешь. Освещаешь свечей корешки книг и читаешь их названия. Белая книга называется «Дождь», серая — «Время». Вот книга зеленая — «Дерево», вот бежевая книга — «Камень». Ты идешь дальше, не зная, как называется книга, которую ты ищешь. Она темно-синяя. Или черная. А, может, ни то и ни другое. Вот ты видишь ее. Темно-синяя. Без названия. Ты протягиваешь к ней руку………………………………………………………...…………………От твоего движения гаснет свеча. Темно. Ничего нет. Нет книжных полок, нет библиотеки, нет старых зеркал и коридора, нет лестницы на второй этаж, нет старого дома, тебя нет. Всё………………………………………………………...…………………………………………………………………………...…………………Звуки капающей воды. Ты слышишь шаги, эхо от которых раздается где-то высоко под сводами коридора. Это идешь ты. Каменный пол. Темно. Вдали виден мерцающий свет факела. Ты выходишь из бокового коридора и оказываешься в полутемном холле на первом этаже старого дома. Под мышкой ты держишь книгу без названия. Темно-синюю. Ты открываешь ее. Страницы исписаны мелким неразборчивым почерком. Кляксы. Некоторые слова зачеркнуты, а вместо них вписаны новые. Кто-то написал книгу о тебе. Страшная догадка вдруг пронзает тебя. Мигом ты взлетаешь. по лестнице на второй этаж, в коридор, к зеркалам, что висят одно напротив другого. Ты снова зажигаешь свечу и подходишь к первому зеркалу. Тысячи седых стариков смотрят на тебя. Это ты. А где-то в глубине зеркального тоннеля идешь молодой ты со свечей в руках, и пламя дрожит от твоего дыхания………………………………………………………...………………… (1 Comment |Comment on this)
9:29 pm	story 003 [Лэди ин рэд] Лэди ин рэд Когда я узнал, что у нее вместо ноги протез, я не слишком-то огорчился. Конечно, это недостаток, но лучше, чем когда нет обеих рук. То, что у нее и вместо рук протезы, я узнал позже, но тоже подумал, что это не очень страшно. В конце концов. протезы у нее хорошие, сразу и не отличишь. Недавно она призналась, что и вместо мозгов она тоже носит протез. Но из качественной резины. Тоже сразу отличить трудно. Какая разница? (Comment on this)