Introduction

• With a clear sense of what we want and what our users want, we can
figure out how to satisfy all those strategic objectives.
• Strategy becomes scope when you translate user
needs and product objectives into specific
requirements for what content and functionality the
product will offer to users.
Defining Project Scope and Requirements

• Defining the scope of your project is both: a valuable process that

results in a valuable product.
• The process is valuable because it forces you to address potential
conflicts and rough spots in the product while the whole thing is still
hypothetical.
• 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 common
language for talking about that work.
• Defining requirements drives ambiguity out of the design process.
• There are two main reasons to bother to define requirements
1. You Know what you are building
2. You know what you are not building
You Know what you are building

• If you clearly articulate exactly what you’re setting out to build,

everyone will know what the project’s goals are and when they’ve
been reached.
• The final product stops being an amorphous picture in the product
manager’s head, and it becomes something concrete that everyone at
every level of the organization, from top executives to entry-level
engineers, can work with.
 You know what you are not building
• Knowing what you’re not building also means knowing what you’re
not building right now.
• The real value in collecting all those great ideas comes from finding
appropriate ways to fit them into your long-term plans.
• By establishing concrete sets of requirements, and stockpiling requests
that don’t fit as possibilities for future releases, you can manage the
entire process in a more deliberate way.
• Some requirements apply to the product as a whole. Branding
requirements are one common example of this; certain technical
requirements, such as supported browsers and operating systems, are
another.
• Other requirements apply only to a specific feature. 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.
• The level of detail in your requirements will often depend on the
specific scope of the project. If the goal of the project is to implement
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.
Functional Specification
• Functional specifications have something of a bad reputation in certain
quarters.
• Programmers often hate specs because they tend to be terribly dull,
and the time spent reading them is time taken away from producing
code.
• Specs reinforces the impression that producing them is a waste of
time.
• it is a bad approach to specs becomes a self-fulfilling prophecy.
• Functional specifications don’t reflect the actual product.
• When things change during implementation, the answer is not to throw
up your hands and declare the futility of writing specs.
• The answer is to make the process of defining specifications
lightweight enough that the spec doesn’t become a project separate
from developing the product itself.
• specs don’t need to capture some idealized future state for the
product—just the decisions that have been made in the course of
creating it.
✔ Writing Down
• Rules apply to writing any kind of requirements.
1. Be positive. Instead of describing a bad thing the system shouldn’t
do, describe what it will do to prevent that bad thing. For example,
instead of this:
The system will not allow the user to purchase 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 buy a
kite without string
2. Be specific. Leaving as little as possible open to interpretation is the
only way we can determine whether a requirement has been fulfilled
 Compare these examples:
1. The most popular videos will be highlighted.
2. Videos with the most views in the last week will appear at the top of the list.
3. Avoid subjective language. This is really just another way of being
specific and removing ambiguity—and therefore the possibility for
misinterpretation—from the requirement.
Content requirements

• Much of the time, when we talk about content, we’re referring to text.
But images, audio, and video can be more important than the
accompanying text.
• These different content types can also work together to fulfill a single
requirement.
• For example, a content feature covering a sporting event might have
an article accompanied by photographs and video clips. 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 expected size of each of your content features has a huge influence on the user
experience decisions you will have to make.
• Your content requirements should provide rough estimates of the size of each
feature: word count for text features, pixel dimensions for images or video, and
file sizes for downloadable, stand-alone content elements like audio files or PDF
documents.
• These size estimates don’t have to be precise—approximations are fine. We only
have to collect the essential information needed to design an appropriate vehicle
for that content.
• Designing a site to provide access to small thumbnail images is different from
designing a site to provide access to full-screen photographs; knowing in advance
the size of THE ELEMENTS OF USER EXPERIENCE 73 the content elements
we have to accommodate enables us to make smart, informed decisions along the
way.
• 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: so everyone on the team
knows exactly what they have to work with in creating the user
experience.
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.
• It’s actually fairly rare that you see a simple one-to-one correlation
between your strategic objectives and your requirements.
• Sometimes one requirement can be applied toward multiple strategic
objectives. Similarly, one objective will often be associated with
several different requirements.
• Because the scope is built upon the strategy, we’ll need to evaluate
possible requirements based on whether they fulfill our strategic goals
.
• Some features can’t be implemented because they’re technically
impossible—for example, there’s just no way to allow users to smell
products over the Web yet, no matter how badly they might want that
ability.
• Other features (particularly in the case of content) aren’t feasible
because they would demand more resources—human or
financial—than we have at our disposal. In other cases, it’s just a
matter of time:
Chapter 2…
Defining the structure
• The realm of structure is the third of the five planes, and appropriately
it is the point at which our concerns shift from the more abstract issues
of strategy and scope to the concrete factors that will determine what
users finally experience.
• In traditional software development, the discipline involved in creating
a structured experience for the user is known as interaction design
• It used to be lumped under the heading of “interface design,” but
interaction design is now recognized as a separate discipline.
• In content development, structuring the user experience is a question
of information architecture.
• This field draws on a number of disciplines that historically have been
concerned with the organization, grouping, ordering, and presentation
of content: library science, journalism, and technical communication,
among others.
• Interaction design and information architecture share an emphasis on
defining patterns and sequences in which options will be presented to
users.
• Interaction design concerns the options involved in performing and
completing tasks.
• Information architecture deals with the options involved in
conveying information to a user.
• Interaction design and information architecture sound like esoteric,
highly technical areas, but these disciplines aren’t really about
technology at all.
• They’re about understanding people—the way they behave and think.
• By building this understanding into the structure of our product, we
help ensure a successful experience for those who use it.
Interaction Design
• Interaction design is concerned with describing possible user behavior
and defining how the system will accommodate and respond to that
behavior.
• 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.
• Programmers have traditionally focused on and cared most about two
aspects of software: what it does and how it does it.
• It is precisely their passion for these details that makes programmers
good at what they do.
• But this focus meant that programmers would gravitate toward
building a system in the way that was most technically efficient
without regard to what worked best for users.
• 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.
• “computer literacy”—teaching people about the inner workings of
computers—was widely considered to be the only way to make users
and software get along.
• The new discipline that arose to help software developers do this is
called interaction design.
Interaction Design Principles

Conceptual model
• Users’ impressions of how the interactive components we create will
behave are known as conceptual models.
• Knowing your conceptual model allows you to make consistent design
decisions. It doesn’t matter whether the content element is a place or
an object; what matters is that the site behaves consistently, instead of
treating the element as a place sometimes and an object at other times.
 • Example:-the conceptual model for the shopping cart component of
a typical e-commerce site is that of a container.
• This metaphorical concept influences both the design of the
component and the language we use in the interface.
• A container holds objects; as a result, we “put things into” and
“take things out of” the “cart,”
• The retail store model is so widely used on the Web that it’s taken on
the status of a convention. If your users do a lot of shopping on other
Web sites, you’ll probably want to stick to that convention.
• The retail store model is so widely used on the Web that it’s taken on
the status of a convention.
• If your users do a lot of shopping on other Web sites, you’ll probably
want to stick to that convention.
• Using conceptual models people are already familiar with makes it
easier for them to adapt to an unfamiliar site. Of course, there’s
nothing wrong with breaking away from convention either—as long as
you have a good reason for doing so and have an alternate conceptual
model that will meet your users’ needs while still making sense to
them.
• 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.
Error handling
• A huge part of any interaction design project involves dealing with
user error.
• The first and best defense against errors is to design the system so
that errors are simply impossible.
• The next best thing to making errors impossible is to make them
merely difficult.
Information Architecture Basics

• 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.
• Information architecture is concerned with how people cognitively
process information, information architecture considerations come up
in any product that requires users to make sense of the information
presented.
Structuring Content
• On content sites, information architecture is concerned with creating
organizational and navigational schemes that allow users to move
through site content efficiently and effectively.
• Information architecture on the Web is closely related to the field of
information retrieval: the design of systems that enable users to find
information easily.
• Web site architectures are often called on to do more than just help
people find things; in many cases, they have to educate, inform, or
persuade users.
• Information architecture problems require creating categorization
schemes that will correspond to our own objectives for the site, the
user needs we intend to meet, and the content that will be incorporated
in the site.
• Categorization scheme in two ways for structuring content: from the
top down, or from the bottom up.

• A top-down approach to information architecture involves creating the

architecture directly from an understanding of strategy plane
considerations: product objectives and user needs.

• Starting with the broadest categories of possible content and

functionality needed to accomplish these strategic goals, we then break
the categories 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 bottom-up approach to information architecture also derives

categories and subcategories, but it does so based on an analysis of the
content and functional requirements.
• Starting with the source material that exists (or that will exist by the
time the site launches), we group items together into low-level
categories and then group those into higher-level categories, building
toward a structure that reflects our product objectives and user needs.
 Top –Down approach Bottom-Top approach
Important details about the content precisely tuned and fitted to the
itself to be overlooked. existing content that it isn’t flexible
enough to accommodate changes or
additions.
• Web sites are living entities. They require constant care and feeding.
Inevitably, they grow and change over time.
• In most cases, a few new requirements acquired along the way
shouldn’t require rethinking the overall structure of the site. 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
reexamination of the organizing principles employed on the site.
• For example, the architecture that enabled users to page through press
releases day-by-day might have been fine when you had only a few
months’ worth, but organizing them by topic might be more practical
after a few year
• The entire user experience, including the structure of the site, is built
on an understanding of your objectives and the needs of your users.
• If what you want to accomplish with the site is redefined or the needs
you intend the site to meet change, be prepared to rework the structure
of your site accordingly.
• 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 Approach
• 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, documents, 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.
• Most Web site architecture projects are only concerned with the
arrangement of pages on the site; by identifying the page as our
base-level node, we make it explicit that we won’t be dealing with
anything smaller.
• If the page itself is too small for the project at hand, we can have each
node correspond to an entire section of the site. If the page is too big,
we can define nodes as individual content elements within the page,
and the page as a group of nodes.
• These nodes can be arranged in many different ways, but these
structures really fall into just a few general classes.
• In a hierarchical structure—sometimes called a tree or hub-and
spoke structure—nodes have parent/child relationships with other
related nodes.
• 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.
• A matrix structure allows the user to move from node to node along
two or more dimensions.
• Matrix structures are often useful for enabling users with different
needs to navigate through the same content, because each user need
can be associated with one axis of the matrix.
• 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. The
human brain simply isn’t very well equipped to visualize movement in
four or more dimensions.
• Organic structures don’t attempt to follow any consistent pattern.
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.
• But organic structures don’t provide users with a strong sense of where
they are in the architecture.
• If you want to encourage a feeling of free-form exploration, such as on
some entertainment or educational sites, an organic structure can be a
good choice; however, it can present a challenge if your users need to
reliably find their way back to the same piece of content again.
• Sequential structures are the ones you are most familiar with from
offline media.
• The sequential flow of language is the most basic type of information
architecture there is, and the faculties needed to process it are built
right into our brains.
• 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
structures 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.
Wireframing and Layout Design

• Wireframing and layout design are fundamental parts of the structure

plane of user experience (UX) design:
• Wireframing A blueprint for a website or app that outlines the
structure, layout, and functionality. Wireframes are a key deliverable
in UX design and are created early in the development process. They
help designers and developers understand how elements like buttons,
headers, navigation, and content blocks will be placed.
• They focus on the information architecture, user flow, and placement
of key elements without delving into visual design or specific details
• Wireframing is invaluable early in the interaction design process for
design teams to explore how concepts accommodate user and business
needs. Designer’s mark out a solution’s bare bones in more detail than
a sketch, including navigation and other features of the design’s
layout.
• Wireframing is distinct from prototyping in the sense that prototyping
deals more with testing interactivity and—when done at the highest
level of fidelity—sophisticated versions that might closely resemble
the released products.
• However, it’s similar in that wireframing can also be done by hand
(e.g., using boxes and lines to represent pictures, text, etc.) or with
software and make low- to high-fidelity versions. In low-fidelity
wireframing, placeholders can be used to mark content and pictures in
grayscale.
Organizing Principle
• Nodes in an information structure are arranged according to organizing
principles.
• 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 principles will be applied in different areas and at
different levels of the site.
• For example, in the case of a corporate information site, we might have
categories near the top of our tree such as “Consumer,” “Business,” and
“Investor.” At this level, the organizing principle is the audience for which
the content is intended. Another site might have top-level categories like
“North America,” “Europe,” and “Africa.” Using geography as an
organizing principle is one approach to meeting the needs of a global
audience.
• The organizing principles you employ at the highest levels of your site
are closely tied to the product objectives and user needs.
• At lower levels in the architecture, issues specific to the content and
functional requirements begin to have a greater influence on the
organizing principles that should be used.
• Any collection of information—whether it consists of two items, 200,
or 2,000—has an inherent conceptual structure.
• In fact, it usually has more than one. That’s part of the problem we
have to solve. The challenge isn’t creating a structure, but creating the
right structure for our objectives and the needs of our users.
• For example, suppose our site contained a repository of information
about cars. One possible organizing principle would arrange the
information according to the weight of the car in question. So the first
thing the user would see would be information about the heaviest car
in our database, then the second heaviest, and on down to the lightest.

• For a consumer information site, this is probably the wrong way to

organize the information. Most people, most of the time, aren’t
concerned with the weight of a car. Organizing the information
according to make, model, or type of car would probably be more
appropriate for this audience.
• On the other hand, if our users are professionals who deal on a daily
basis with the business of shipping cars overseas, weight becomes a
very important factor. For these people, qualities like fuel economy
and engine type are considerably less important, if they matter at all.
• These attributes, in the language of library science, are known as
facets, and they can provide a simple, flexible set of organizing
principles for almost any content.
Language and metadata
• It is essential to use the language of your users and to do so in a
consistent fashion. The tool we use to enforce that consistency is
called a controlled vocabulary.
• A controlled vocabulary is nothing more than a set of standard terms
for use on the site. This is another area in which user research is
essential.
• Talking to users and understanding how they communicate is the most
effective way to develop a system of nomenclature that will feel
natural to them.
• Creating and adhering to a controlled vocabulary that reflects the
language of your users is the best way to prevent your organization’s
internal jargon from creeping onto the site, where it will only confuse
your users.
• Controlled vocabularies also help create consistency across all your
content.
• Whether the people responsible for producing the content sit right
next to each other or in offices on separate continents, the controlled
vocabulary provides a definitive resource to ensure that everyone is
speaking the user’s language.
• A more sophisticated approach to controlling vocabulary is to create a
thesaurus.
• Connecting your search engine with a thesaurus and providing
metadata for your content can help make the engine smarter.
• The search engine can use the thesaurus to map a search for a
disallowed term to a preferred term; then it can check the metadata for
that preferred term.
• Instead of getting no results at all, the user gets highly targeted,
relevant results—and maybe even some recommendations for other
related subjects that might be of interest.