The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition) (Voices That Matter) (English Edition) 2nd Edition, eBook Kindle. Read "Elements of User Experience,The User-Centered Design for the Web and Beyond" by Jesse James Garrett available from Rakuten Kobo. Sign up today. An ultimate list of ALL free books on Usability UX UI User Centered Design Free ebook: The Essential Elements of Successful UX Design.
|Language:||English, Spanish, Indonesian|
|Genre:||Science & Research|
|Distribution:||Free* [*Registration needed]|
THE ELEMENTS OF USER EXPERIENCE S E CO N D E D I T I O N USER CENTERED DESIGN F O R T H E W E B A N D B E YO N D Written and Illustrated by. The user experience development process is all about ensuring that no aspect of the user's experience with your site happens without your conscious, explicit. The Elements of User Experience cuts through the complexity of user-centered Jesse James Garrett gives readers the big picture of Web user experience.
Consider a simple product such as a chair or a table. To use the chair you sit on it; to use the table you place other objects on it. But the manufacturers of chairs and tables tend not to employ user experience designers. Each additional feature, function, or step in the process of using a product creates another opportunity for the experience to fall short. A modern mobile phone has many, many more functions than a desk phone of, say, the s. As a result, the process of creating a successful product has to be quite different.
User Experience and the Web User experience is vital to all kinds of products and services. This book is primarily about the user experience of one particular kind of product: Web sites. Web sites are complicated pieces of technology, and something funny happens when people have trouble using complicated pieces of technology: They blame themselves. They feel like they must have done something wrong. They feel stupid. But they feel stupid anyway.
Regardless of the type of site, in virtually every case, a Web site is a self-service product. There is no instruction manual to read beforehand, no training seminar to attend, no customer service representative to help guide the user through the site. There is only the user, facing the site alone with only her wits and personal expe- rience to guide her. Faced with a wide array of choices, the user is left to her own devices to determine which fea- tures of a site will meet her needs.
Despite the vital strategic importance of user experience to the suc- cess of a Web site, the simple matter of understanding what people want and need has been a low priority for most of the history of the medium. If user experience is such a vital part of any Web site, why is it so often neglected in the development process? In the earliest days of the Web, sites like Yahoo! Established companies raced to set up Web sites, determined not to be perceived as falling behind the times.
But in most cases, companies considered merely having deployed the site a great accomplishment; whether the site actually worked for people was, at best, an afterthought. This race to cram more features into products is hardly unique to the Web; from wristwatches to mobile phones, featuritis is endemic to many product categories.
Having more features, however, turns out to be only a temporary source of competitive advantage.
All you provide is information about your company. It might seem that you have a monopoly on that information—if people want it, they have to get it from you.
If your site consists mainly of what Web pros call content—that is, information—then one of the main goals of your site is to com- municate that information as effectively as possible. It has to be presented in a way that helps people absorb it and understand it. Features and functions always matter, but user experience has a far greater effect on customer loyalty.
Businesses with an eye on the bot- tom line want to know about the return on investment, or ROI. ROI is usually measured in terms of money: For every dollar you spend, how many dollars of value are you getting back? But return on investment does not have to be expressed in strictly monetary terms. All you need is a measurement that shows that your money going out translates into value for your company.
One common measure of return on investment is conversion rate. By keeping track of what per- centage of users you convert to the next level, you can measure how effectively your site is meeting your business goals. Far more people browse a commerce site than download from it. A quality user experience is a key factor in converting these casual browsers into active downloaders. Even a tiny increase in your conversion rate can translate into a dramatic leap in revenue. Conversion rate tracks how successful you are in getting those who visit to spend some money.
Whether they are used by your customers, your partners, or your employees, Web sites can have all kinds of indirect effects on the bottom line. No one outside your company might ever see the site you run as in the case of an internal tool or an intranet , but the user experi- ence still makes a huge difference. Often, it can mean the differ- ence between a project that creates value for the organization and a project that becomes a resource-consuming nightmare.
This basi- cally comes in two key forms: The less time it takes to complete any given task, the more you can get done in a day. In keeping with the old notion that time is money, saving your employees time translates directly into saving your business money. People like their jobs more when their tools are natural and easy to use, not frustrating and needlessly complex.
The concept of user-centered design is very simple: Take the user into account every step of the way as you develop your product.
The implications of this simple concept, however, are surprisingly complex. Everything the user experiences should be the result of a conscious decision on your part.
Realistically, you might have to make a com- promise here and there because of the time or expense involved in creating a better solution. The biggest reason user experience should matter to you is that it matters to your users.
For the users who do come, you must set out to provide them with an experience that is cohesive, intuitive, and maybe even pleasurable—an experience in which everything works the way it should. No matter how the rest of their day has gone. It sounds like a big job, and in some ways it is. But by breaking the job of crafting the user experience down into its component elements, we can better understand the task as a whole.
The Five Planes Most people, at one time or another, have downloadd a physical product over the Web. The experience is pretty much the same every time: If we peel away the layers of that experience, we can begin to understand how those decisions are made. The Surface Plane On the surface you see a series of Web pages, made up of images and text. Some of these images are things you can click on, per- forming some sort of function such as taking you to a shopping cart.
Some of these images are just illustrations, such as a photograph of a product for sale or the logo of the site itself. The Skeleton Plane Beneath that surface is the skeleton of the site: The Structure Plane The skeleton is a concrete expression of the more abstract structure of the site.
Just what those features and functions are constitutes the scope of the site. For example, some commerce sites offer a feature that enables users to save previously used shipping addresses so they can be used again. Whether that feature—or any feature—is included on a site is a question of scope.
The Strategy Plane The scope is fundamentally determined by the strategy of the site. This strategy incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well.
In the case of our store example, some of the strategic objectives are pretty obvious: Users want to download products, and we want to sell them. Other objectives—such as the role that advertis- ing or content produced by our users plays in our business model, for example—might not be so easy to articulate. On each plane, the issues we must deal with become a little less abstract and a little more concrete.
On the highest plane, we are only concerned with the most concrete details of the appearance of the product. So, the surface depends on the skeleton, which depends on the structure, which depends on the scope, which depends on the strategy. Conversely, the choices available to us on each plane are constrained by the decisions we make about issues on the planes below it.
At each level, we make decisions according to what the competition is doing, industry best practices, what we know about our users, and plain old common sense. These decisions can have a ripple effect in both directions. Requiring work on each plane to finish before work on the next can start leads to unsatisfactory results effort for you and your users.
The impor- tant consideration here is to not build the roof of the house before you know the shape of its foundation. All these seemingly identical terms are thrown around: What do they mean? Or are they just more meaningless industry buzzwords? To further complicate matters, people will use the same terms in different ways. When the Web started, it was all about information. People could create documents, and they could link them to other documents.
He knew the Web had the potential to be much more than that, but few others really understood how great its potential was. People originally seized on the Web as a new publishing medium, but as technology advanced and new features were added to Web browsers and Web servers alike, the Web took on new functional capabilities. After the Web began to catch on in the larger Internet community, it developed a more complex and robust feature set that would enable Web sites not only to distribute information but to collect and manipulate it as well.
Technol- ogy continued to advance on both fronts as all kinds of sites made the transition from static collections of information that changed infrequently to dynamic, database-driven sites that were constantly evolving. When the Web user experience community started to form, its members spoke two different languages. One group saw every prob- lem as an application design problem, and applied problem-solving approaches from the traditional desktop and mainframe software worlds.
These, in turn, were rooted in common practices applied to creating all kinds of products, from cars to running shoes. The other group saw the Web in terms of information distribution and retrieval, and applied problem-solving approaches from the tradi- tional worlds of publishing, media, and information science. This became quite a stumbling block. Very little progress could be made when the community could not even agree on basic terminol- ogy.
The waters were further muddied by the fact that most Web sites could not be neatly categorized as either functional applica- tions or information resources—a huge number seemed to be a sort of hybrid, incorporating qualities from each world. Here, we consider the product as a tool or set of tools that the user employs to accomplish one or more tasks.
On the opposite side, our concern is what information the product offers and what it means to our users. The Elements of User Experience Now we can map that whole confusing array of terms into the model.
The Strategy Plane The same strategic concerns come into play for both functionality- oriented products and information-oriented resources. Balanced against user needs are our own objectives for the site.
On the information side, scope takes the form of content requirements: Chapter 4 will cover the scope elements. For information resources, the structure is the information architecture: The Skeleton Plane The skeleton plane breaks down into three components. On both sides, we must address information design: For functionality-oriented products, the skeleton also includes inter- face design, or arranging interface elements to enable users to interact with the functionality of the system.
The interface for an information resource is its navigation design: The Surface Plane Finally, we have the surface. Regardless of whether we are dealing with a functionality-oriented product or an information resource, our concern here is the same: In reality, of course, the lines between these areas are not so clearly drawn. Can a change to the visuals do the trick, or will the underlying navigation design have to be reworked? Few products or services fall exclusively on one side of this model or the other.
The way organizations delegate responsibility for user experience issues often complicates matters further. In some organizations, you will encounter people with job titles like information architect or interface designer.
These people gener- ally have expertise spanning many of the elements of user experi- ence, not just the specialty indicated by their title. The content that is available to you or that you have resources to obtain and manage will play a huge role in shaping your site. In the case of an online store, we might decide that we want the users to be able to see cover images of all the books we sell.
If we can get them, will we have a way to catalog them, keep track of them, and keep them up to date? These content questions are essential to the ultimate user experience of the site. Second, technology can be just as important as content in cre- ating a successful user experience. In many cases, the nature of the experience you can provide your users is largely determined by technology.
In the early days of the Web, the tools to connect Web sites to databases were fairly primitive and limited. As the technology has advanced, however, databases have become more widely used to drive Web sites. This in turn has enabled more and more sophisticated user experience approaches, such as dynamic navigation systems that change in response to the way users move through the site. Nevertheless, the funda- mental elements of user experience remain the same.
If you work on the Web, everything in this book applies to you. Even if you work on products or services that have nothing to do with technol- ogy, you can map these concepts to your own processes. The rest of this book looks at these elements, plane by plane, in greater detail.
Knowing both what Scope we want the product to accomplish for our organi- Strategy zation and what we want it to accomplish for our users informs the decisions we have to make about every aspect of the user experience. But answer- ing these simple questions can be trickier than Sensory Design it looks. What do we want to get out of this product? What do our users want to get out of it? The second question addresses user needs, objectives imposed on the product from outside.
Together, product objectives and user needs form the strat- egy plane, the foundation for every decision in our process as we design the user experience. Yet, amazingly, many user experience projects do not begin with a clear, explicit understanding of the underlying strategy. The more clearly we can articulate exactly what we want, and exactly what others want from us, the more precisely we can adjust our choices to meet these goals.
Too often, product objectives exist only as an unspoken understanding among those building the product. When that understanding remains unspoken, different people often have different ideas about what the product is sup- posed to accomplish. Business Goals People commonly use terms like business goals or business drivers to describe internal strategic objectives. Most people start out describing objectives for their products in very general terms.
In the case of Web sites, they fundamentally serve one of two purposes: But exactly how these sites are supposed to do that is not always clear.
Brand Identity One essential consideration in formulating the objectives for any product is brand identity. When most of us see the word branding, we think of things like logos, color palettes, and typography. In the minds of your users, an impression about your organization is inevitably created by their interactions with your product. You must choose whether that impression happens by accident or as a result of conscious choices you have made in designing your product.
An important part of understanding your objectives is understanding how you will know when you have reached them. These are known as success metrics: Sometimes these metrics are related to the product itself and how it is used. How much time does the average user spend on your site during each visit? Analytics tools can help you determine this. On the other hand, if you want to provide quick, get-in-get-out access to information and functionality, you may want to decrease the time per visit.
In this example, measuring 7 the number of visits per registered user per 6 month indicates how 5 valuable the site is to its core audience. But you have to be careful to balance your objectives and the needs of your users.
And in the long run, it will show: As your users get frustrated and decide not to come back, your impressions will drop from that initial high and will probably end up lower than they were when you started.
You can measure the indirect effects of the site as well. If your site provides solutions to common problems people encounter with your product, the number of phone calls coming into your cus- tomer support lines should go down. An effective intranet can pro- vide ready access to tools and resources that can cut down on the time it takes for your salespeople to close a sale—which, in turn, translates directly into increased revenue.
For success metrics to meaningfully drive user experience deci- sions, those metrics must be clearly tied to aspects of user behavior that can be shaped by our design choices. By spending time researching those needs, we can break out of our own limited perspective and see the site from the point of view of the users.
Identifying user needs is complicated because users can be quite diverse. If we are creating a mobile app intended for a consumer audience, the possibilities increase exponentially. User Segmentation We can break this mass of user needs down into manageable chunks through user segmentation. We divide our audience into smaller groups or segments consisting of users with certain key characteristics in common. There are nearly as many ways to seg- ment user groups as there are types of users, but here are a couple of the most common approaches.
Market researchers commonly create audience segments based on demographic criteria: Psychographics often correlate strongly with demographics: People in the same age group, location, and income level often have similar attitudes. But in many cases, demographi- cally identical people have very different ways of seeing and inter- acting with the world.
Just think of everybody you went to high school with. How much time do your users spend using the Web every week? Is technology a part of their daily lives? Do they like working with technology products? Do they always have the latest and greatest products, or do they only upgrade when they have to? Technophobes and power users approach Web sites in very different ways, and our designs need to accommodate them.
Answers to questions like these can help us do just that. Selling cookware to people just learning their way around a kitchen must be handled very differently from selling to professional cooks.
Similarly, a stock- trading application used by those unfamiliar with the stock market will require a different approach from one for seasoned investors. These differences in experience or expertise can form the basis for segmenting our audience. The information needs of the parents of a student applying for college are different from those of the student herself.
If the difference is great enough, you might want to treat these as separate groups, rather than the single 25—34 group you started with. On the other hand, if the 18—24 group seems pretty similar to the 25—34 group, maybe you can combine them. Creating user segments is just a means to the end of uncovering user needs. You really only need as many different segments as you have different sets of user needs.
Not only will different groups of users have different needs, but sometimes those needs will be in direct opposition. Take the preceding exam- ple of the stock-trading application.
The novices would probably be best served by an application that broke the process down into a sequence of simple steps. For the experts, however, such a sequence would be a hindrance.
Whichever course we choose, this stra- tegic decision will have consequences for every additional choice we make about the user experience. Some research tools—such as surveys, interviews, or focus groups— are best suited for gathering information about the general attitudes and perceptions of your users.
Generally, the more time you spend with each individual user, the more detailed the information you will get from the research study. Market research methods like surveys and focus groups can be valuable sources of general information about your users.
The more clearly you can describe what you want, the more narrowly and effectively you can formulate the questions you ask to ensure that you get the right information. These techniques are derived from the methods used by anthropologists to study cultures and societies. Applied on a smaller scale, the same methods used to examine, for example, how a nomadic tribe functions, can also be used to examine how people who download aircraft parts function. The only downside is that contextual inquiry can be very time-consuming and very expen- sive.
In other cases, contextual methods can be lightweight and inex- pensive, although they tend not to produce the deep understanding of a full research study. One example of a method closely related to contextual inquiry is task analysis. Task analysis is a method of closely examining the precise steps users go through in accomplishing those tasks. User testing is the most commonly employed form of user research. This word means different things to different people. Some people use it to refer to the practice of testing designs with representative users.
Every approach to usability seeks to make products easier to use. Some of them even agree with each other. But they all have the same principle at their core: Users need usable products. Tests with a fully operational Web site can be very broad or very narrow in scope. User testing can also investigate broader, less concrete issues. Another approach to user testing is to have users work with pro- totypes.
You can recruit users to perform a variety of exercises that can give you insights into how they approach the subject matter of your site. For infor- mation-oriented sites, card sorting is one method used to explore how users categorize or group information elements. The user is given a stack of index cards, each of which has the name, descrip- tion, or image of a piece or type of content on it.
The user then sorts the cards into piles according to the groups or categories that feel most natural. Analyzing the results of card sorts conducted with several users can help us understand how they think about the information our site provides. Creating Personas Collecting all sorts of data about your users can be incredibly valu- able, but sometimes you can lose sight of the real people behind all the statistics.
By putting a face and a name on the disconnected bits of data from your user research and segmentation work, personas can help ensure that you keep the users in mind during the design process. Suppose our site is designed to provide information for people who are starting their own businesses. We know from our research that our audience mostly falls in the 30—45 age range. Our users tend to be fairly comfortable with the Web and technology in general.
In this case, it might be appropriate to create two personas. The second persona is Frank. Where did all this information come from? Well, for the most part, we made it up. How would Frank react to it? I need quick answers. Fairly comfortable with technology; Dell Occupation: I want a site that will explain everything. Somewhat uncomfortable with technology; Occupation: But despite this fact or perhaps because of it , responsibility for formulating these objectives often falls through the cracks.
Strategists will talk to many people throughout the organization to get as many perspectives as possible on the questions of prod- uct objectives and user needs. Stakeholders are senior decision- makers who are responsible for parts of the organization that will be affected by the ultimate strategic direction of the product.
For example, in the case of a Web site designed to provide customers with access to product support information, stakeholders might include representatives from marketing communications and cus- tomer service as well as product managers. It depends on the formal decision-making structure and the informal political realities of the organization. No one knows what customers are having trouble with better than the people who talk to those customers every day.
These quotes vividly illustrate the strategic issues involved in the project. User needs are sometimes documented in a separate user research report though there are certain advantages to having all your information in one place. Bigger is not necessarily better when it comes to documenting your strategy.
Keep it concise and to the point. An effective strategy document not only serves as a touchstone for the user experience development team; it can also be used to build support for the project in other parts of the organization. Strategy documents often contain sensitive material, but organiza- tions can go too far and keep the strategy away from the responsible team, which undermines their ability to realize it.
Strategy becomes scope when Strategy you translate user needs and product objectives into specific requirements for what content and function- ality the product will offer to users. We can identify what we can tackle now and what will have to wait until later. The product is valuable because it gives the entire team a reference point for all the work to be done throughout the project and a com- mon language for talking about that work.
I once worked on a Web application that seemed to be in a state of perpetual beta: Every new article some- body read or every new thought that came along while somebody was playing with the product inspired another feature for consider- ation. Reason 1: Or even worse, everyone assumes someone else is managing the design and devel- opment of some crucial aspect of the product, when in fact no one is.
Seeing the entire scope mapped out enables you to see connections between individual requirements that might not otherwise be apparent. Reason 2: Additionally, all sorts of possibilities for features emerge after the project is well underway.
Version 1. Likewise, each additional requirement may not seem like that much extra work. Some organizations use these terms to mean two different documents: The language of this chapter is mostly the language of software development. But the concepts here apply equally to content. The purposes and approaches are the same. Content requirements often have functional implications. These days, pure content sites are usually handled through a content management system CMS. You might decide to download a proprietary content management system, use one of the many open-source alternatives, or even build one from scratch.
In any case, it will take some tinkering to tailor the system to your organization and your content. Will you be maintaining content in multiple languages or data formats? The CMS will need to be able to handle all those kinds of content elements. Does every press release need to be approved by six exec- utive vice presidents and a lawyer? Will content elements be dynamically recombined according to the preferences of each user, or the device they are using?
The CMS will need to be able to accomplish that level of complex delivery. Similarly, the functional requirements of any technology product have content implications. How about error messages? Some- body has to write those. Countless allegedly technical projects could have been improved immeasurably if the developers had simply taken the time to have someone look at the application with an eye toward content.
Branding requirements are one common example of this; certain technical requirements, such as supported browsers and operating systems, are another.
Most of the time when people refer to a requirement, they are thinking of a short description of a single feature the product is required to have. If the goal of the project is to imple- ment one very complex subsystem, a very high level of detail might be needed, even though the scope of the project relative to the larger site might be quite small. Conversely, a very large-scale content project might involve such a homogeneous base of content such as a large number of functionally identical PDFs of product manuals that the content requirements can only be very general.
The most productive source for requirements will always be your users themselves. But more often, your requirements will come from stakeholders, people in your organization who have some say over what goes into your product. The user research techniques outlined in Chapter 3 can all be used to help you get a better understanding of the kinds of features users want to see in your product. First, and most obvious, are the things people say they want.
Sometimes the things people say they want are not the things they actually want. Sometimes that solution is unworkable, or it addresses a symptom rather than the underlying cause of the problem. By exploring these suggestions, you can sometimes arrive at completely different requirements that solve the real problem.
These often come out of brainstorming exercises, when participants have a chance to talk through and explore the possibilities for the project. Ironically, sometimes the people most deeply involved in creating and working with a product are the ones least able to imagine new directions for it. When you spend all your time immersed in main- taining an existing product, you can often forget which of your constraints are real, and which are simply products of historical choices.
Hearing unfamiliar perspectives—and having the opportunity to respond to them—encourages people to think in broader terms about both the problems involved in develop- ing the product and the possible solutions.
Whatever device we are designing for—or if we are designing the device itself—our feature set will need to take into account hard- ware requirements, too. Does the device have a camera? Gyroscopic position sensors? These considerations will inform and constrain your functional possibilities.
By imagining the process our users might go through, we can come up with potential requirements to help meet their needs. We can also look to our competitors for inspiration. Anyone else in the same business is almost certainly trying to meet the same user needs and is probably trying to accomplish similar product objec- tives as well. Has a competitor found a particularly effective feature to meet one of these strategic objectives? How have they addressed the same trade-offs and compromises we face?
Some gaming platforms, for example, offer users the ability to create social groups of fellow players. Adopting or building on their approach when scoping a similar feature for our digital video recorder may give us an advan- tage over our direct competition. Programmers often hate specs because they tend to be terribly dull, and the time spent reading them is time taken away from producing code. As a result, specs go unread, which in turn reinforces the impression that producing them is a waste of time—because it is!
Things change during implementation. This, however, is not a reason to abandon writing specs as a lost cause. Instead, it highlights the importance of specs that actually work. When things change during implementation, the answer is not to throw up your hands and declare the futility of writing specs.
Writing It Down No matter how large or complex the project may be, a few general rules apply to writing any kind of requirements.
Be positive. For example, instead of this: The system will not allow the user to download a kite without kite string. This would be better: The system will direct the user to the kite string page if the user tries to download a kite without string.
Compare these examples: The most popular videos will be highlighted. Videos with the most views in the last week will appear at the top of the list. What counts as popular? Videos with the most comments?
And what constitutes highlighting them? By removing the possibility of differing interpretations, the second requirement neatly skirts the kinds of arguments likely to crop up during or after implementation.
Avoid subjective language. The site will meet the hipness expectations of Wayne, the mail clerk. So perhaps this require- ment would be best of all: The look of the site will conform to the company branding guidelines document. The whole concept of hipness has now disappeared entirely from the requirement.
Instead, we have a clear, unambiguous reference to established guidelines. But images, audio, and video can be more important than the accompanying text. Identifying all the content types associated with a feature can help you determine what resources will be needed to produce the content or whether it can be produced at all.
The real value of an FAQ to users is that it provides ready access to commonly needed information. Your content requirements should provide rough estimates of the size of each feature: We only have to collect the essential information needed to design an appro- priate vehicle for that content.
Once it has been validated against our strategic objectives, any content feature inevitably sounds like a really good idea—as long as someone else is responsible for creating and maintaining it. Content is hard work. You might be able to hire on contract resources or, more likely, stick someone down in marketing with the job to create the content in time for the initial launch, but who will keep it up to date?
Content—well, effective content, anyway— requires constant maintenance. Approaching content as if you can post it and forget it leads to a site that, over time, does an increas- ingly poor job of meeting user needs. This is why, for every content feature, you should identify how frequently it will be updated. The frequency of updates should be derived from your strategic goals for the site: Based on your product objectives, how often do you want users to come back?
Based on the needs of your users, how often do they expect updated informa- tion? If your site has to serve multiple audiences with divergent needs, knowing which audience a piece of content is intended for can help you make better decisions about how to present that content. Information intended for children requires a different approach from information intended for their parents; information for both of them needs yet a third approach.
For projects that involve working with a lot of existing content, much of the information that will feed your requirements is recorded in a content inventory. Taking an inventory of all the content on your existing site may seem like a tedious process—and it usually is. But having the inventory which usually takes the form of a simple, albeit very large, spreadsheet is important for the same reason that having concrete requirements is important: Prioritizing Requirements Collecting ideas for possible requirements is not hard.
Almost everyone who regularly comes in contact with a product—whether they are inside the organization or outside—will have at least one idea for a feature that could be added. The tricky part is sorting out what features should be included in the scope for your project.
In other cases, one requirement can serve multiple strategic objectives right. Some- times one requirement can be applied toward multiple strategic objectives.
Similarly, one objective will often be associated with several different requirements. How feasible will it be to actually make this stuff? The feature would take three months to implement, but we have an executive requirement to launch in two.
In the case of time constraints, you can push features out to a later release or project milestone. For resource constraints, technological or organizational changes can sometimes—but, importantly, not always—reduce the resource burden, enabling a feature to be imple- mented. However, impossible things will remain impossible. Few features exist in a vacuum. Even content features on a Web site rely on the features around them to inform the user on how best to use the content provided.
Some features will require trade-offs with others in order to produce a coherent, consistent whole. Is it preferable to go with a multiple-step process, or should you rework the database system? It depends on your strategic objectives.
In these cases, whether features end up in the project scope all too often comes down to corporate politics. When stakeholders talk about strategy, they usually start out with feature ideas, and then have to be coaxed back to the underlying strategic factors.
Because stakeholders often have trouble separating features from strategy, certain features will often have champions. Focus on strategic goals, not proposed means of accomplishing them. Admittedly, this is often easier said than done. This is the next level up from scope: Interaction design concerns the options involved in performing and completing tasks. Information architecture deals with the options involved in conveying information to a user.
By building this understanding into the structure of our product, we help ensure a successful experience for those who use it. Any time a person uses a product, a sort of dance goes on between the two of them.
The user moves around, and the system responds. Then the user moves in response to the system, and so the dance goes on. The system could just do its thing, and if some toes got stepped on, well, that was part of the learning process. But every dancer will tell you that for the dance to really work, each participant must anticipate the moves of the other. Programmers have traditionally focused on and cared most about two aspects of software: Especially back when computing power was a limited resource, the best approach was the one that got the job done within those technical limitations.
The approach that works best for the technology is almost never the approach that works best for the person using it. Thus, software acquired the reputation that has haunted it for most of its existence: Software is complicated, confusing, and hard to use. The new discipline that arose to help software developers do this is called interaction design.
For example, does the system treat a particular feature as a thing the user consumes, a place the user visits, or an object the user acquires? Different sites take different approaches.
Knowing your conceptual model allows you to make consistent design decisions. For example, the conceptual model for the shopping cart compo- nent of a typical e-commerce site is that of a container. Suppose the conceptual model for the component were a differ- ent real-world analog, such as a catalog order form. The system might provide an edit function that would replace both the add and remove functions of the traditional cart, and instead of using a checkout metaphor to complete the process, users might send their orders in.
Which to choose? Using conceptual models people are already familiar with makes it easier for them to adapt to an unfamiliar site. Unfamiliar conceptual models are only effective when users can correctly understand and interpret them. A conceptual model can refer to just one component of a system or to the system as a whole. When the news and commentary site Slate launched, its conceptual model was a real-world magazine: Understanding the models users themselves bring to the site Does it work like a retail store?
Does it work like a catalog? The home page of the site for Southwest Airlines used to consist solely of a picture of a customer service desk, with a stack of brochures to one side, a telephone to the other side, and so on.
Southwest must have gotten tired of being used as a bad example; its site subsequently became light on metaphor and con- siderably more functional. The old Southwest Airlines site is a classic example of conceptual models being tied too closely to real-world counterparts.
A good example of this type of defense can be seen in any car with an automatic transmission. Bad for the car, bad for the driver, and possibly bad for an innocent bystander who happens to be in the path of the lurching car. But even with such measures in place, some errors are bound to happen. But be careful— some of the most irritating behavior of software products results from well-intentioned efforts to correct user errors.
In these cases, the system should provide a way for users to recover from the error. The best-known example of this is the famous undo function, but error recovery can take many different forms.
Of course, this warning is only effective when users actu- ally notice it. For as long as people have had information to convey, they have had to make choices about how they structure that information so other people can understand and use it.
Because information architecture is concerned with how people cognitively process information, information architecture consid- erations come up in any product that requires users to make sense of the information presented. Most commonly, information architecture problems require creat- ing categorization schemes that will correspond to our own objec- tives for the site, the user needs we intend to meet, and the content that will be incorporated in the site.
We can tackle creating such a categorization scheme in two ways: A top-down approach to information architecture involves cre- ating the architecture directly from an understanding of strategy plane considerations: Starting with the broadest categories of possible content and functionality needed to accomplish these strategic goals, we then break the cat- egories down into logical subsections.
This hierarchy of categories and subcategories serves as the empty shell into which the content and functionality will be slotted. A top-down architectural approach is driven by considerations from the strategy plane. Approaching the archi- tecture from the top down can sometimes cause important details about the content itself to be overlooked. The categories just have to be the right ones for your users and their needs. Some people favor counting the number of steps it takes to complete a task or the number of clicks it takes for a user to reach a particular destination as a way to evaluate the quality of a site structure.
The most important sign of quality, however, is not how many steps the process took, but whether each step made sense to the user and whether it followed naturally from the previous step. Web sites are living entities.
They require constant care and feed- ing. Inevitably, they grow and change over time. One trait of an effective structure is its ability to accommodate growth and adapt to change. But the accumulation of new content will eventually require a re- examination of the organizing principles employed on the site. The entire user experience, including the structure of the site, is built on an understanding of your objectives and the needs of your users.
The need for such structural change rarely announces itself in advance, though; often, by the time you can tell that you need to rework the architecture, your users are already suffering. Architectural Approaches The basic unit of information structures is the node. A node can correspond to any piece or group of information—it can be as small as a single number like the price of a product or as large as an entire library.
By dealing with nodes rather than with pages, docu- ments, or components, we can apply a common language and a common set of structural concepts to a diverse range of problems.
The abstraction of nodes also allows us to explicitly set the level of detail we will be concerned with. These nodes can be arranged in many different ways, but these structures really fall into just a few general classes. Child nodes represent narrower concepts within the broader category represented by the parent node. Not every node has children, but every node has a parent, leading all the way up to the parent node of the entire structure or the root of the tree, if you prefer.
Because the concept of hierarchical relationships is well understood by users and because software tends to work in hierarchies anyway, this type of structure is far and away the most common. Hierarchical structure. A matrix structure allows the user to move from node to node along two or more dimensions.
For example, if some of your users really want to browse products by color, but others need to browse by size, a matrix can accommodate both groups. A matrix of more than three dimensions can cause problems, however, if you expect users to rely on it as their primary navigational tool. Matrix structure. Nodes are connected together on a case-by-case basis, and the architecture has no strong concept of sections. Organic structures are good for exploring a set of topics whose relationship is unclear or evolving.
Books, articles, audio, and video are all designed to be experienced in a sequential fashion. Sequential structures on the Web are used most often for smaller-scale struc- tures such as individual articles or sections; large-scale sequential structures tend to be limited to applications in which the order of content presentation is essential to meeting user needs, such as in instructional material.
Sequential structure. At its most basic level, the organizing principle is the criterion by which we determine which nodes are grouped together and which are kept separate.
Different organizing prin- ciples will be applied in different areas and at different levels of the site. Generally, the organizing principles you employ at the highest lev- els of your site are closely tied to the product objectives and user needs. For example, a site with news-oriented content will often have chronology as its most prominent organizing principle.
Timeliness is the single most important factor for users who, after all, look to news sites for information on current events, not history as well as for the creators of the site who must emphasize the timeliness of their content in order to remain competitive.
In fact, it usually has more than one. For example, suppose our site contained a repository of informa- tion about cars. Habilitado X-Ray: Information Architecture: For the Web and Beyond English Edition. UX Research: Compartilhe seus pensamentos com outros clientes. Compra verificada. Having worked in this industry for many years, I was pleasantly surprised to come across such a clear primer. Although this book borders on conceptual, it covers enough practical details to make it an invaluable resource for those new to the trade, or anyone looking to improve their process with industry best practices.
This is a book I will now highly recommend to anyone new to our organization. It also provided me with a great set of tools to help explain the process to others including clients. I think that the this is a good book, but it kinda falls short ehen it comes to concrete examples of planning interaction. As far as I understood, the author suggest using the framework described in the book for managing software solutions as a whole.
The framework itself is not bad, but the scope, strategy and stru ture planes kinda try to steal away the glory from the good old fashioned software requirement specification document. It works fine as a reference, but unless it's required, I would skip it. JJG's visuals are well known within the industry and I have copies of them downloaded from his site and posted to the wall of my cube as reminders when I jump into any new project.
Garrett has made a reputation in the Web world through his time at the helm of Adaptive Path, which he founded several years ago. Back in , he published this book, aimed at providing a framework for designing for the Web and arguably for other media with the user in mind. His proposed methodology is so effective that, even five years after the publishing date, the book still is valuable and relevant. The only parts in the book where time has made it less useful are the sections at the end of each chapter, where Garrett proposes Further Reading resources, many of which have already been superseded with more recent publications.
As for the framework, Garrett proposes an approach that goes from general to specific, laying out the groundwork first by getting the strategy plane solidified with clear site objectives based on user needs. Once the strategy is clear, the scope of the project can be defined, through functional specifications and a description of content requirements.
The next layer up corresponds to the structure plane, where interaction design and information architecture take place. Next up, in the skeleton plane the interface, navigation and information design in the form of the familiar wireframes can be designed, leaving for last the visual design at the surface plane.