Tuesday, May 22, 2007

The Elements of User Experience (I)

Started a new book, The Elements of User Experience. The author has a great framework for how to think about designing a website.

First, he asserts that there are 2 ways to think about the web: (1) as a software interface, (2) as a hypertext system. With software interface, the designer is concerned mostly with tasks. We can consider the website as a tool or set of tools that the user employs to accomplish one or more tasks. For example, search/browse, upload a file, etc. With the hypertext model, the designer is concerned with information. What information or content does the site offer, and what does it mean to its users?

You can then break down the website design into discrete levels, including:

  • Strategy
  • Scope
  • Structure
  • Skeleton
  • Surface

WRT strategy, there are 2 elements that span both views of the website as a SW interface as well as a hypertext system:

  1. User needs: goals for the site that come from users
  2. Site objectives: our own objectives for the site

WRT scope, there are functional specifications for the SW interface view, and content requirements for the hypertext view.

WRT structure, interaction design defines how the system behaves in response to a user (SW interface view). Information architecture is the arrangement of content elements within the information space (hypertext view).

WRT skeleton, information design affects the presentaion of information in a way that indicates understanding (applies to both SW interface, and hypertest views). Interface design arranges the interface elements to enable users to interact with the functionality of the system. The interface for an information space is its navigation design.

Finally, the surface, which is concerned mostly with visual design, or the look of the finished product.

Saturday, May 19, 2007

4 Approaches for User-Centered Design

From "Designing for Interaction" by Dan Saffer

1. User-centered design (UCD)

2. Activity-centered design

3. Systems design

4. Genius design

1. User-centered design

Focuses on user needs and goals

Goals are really important in UCD; designers focus on what the user ultimately wants to accomplish

Designer then determines the tasks necessary to achieve those goals, but with the users' needs and preferences always in mind

Designers involve users in every stage of the project; user data is the determining factor in making design decisions

Pros: Gets designers to focus on needs and goals of users, rather than their own preferences ("You are not the user")

Cons: May result in a product that is too narrowly focused; also, may be designed for the wrong set of users

2. Activity-centered design

Focuses on the tasks and activities that need to be accomplished

Typically functional products (e.g. appliances, cars) use activity-centered design

Activities are made up of tasks; each task is a moment in the life of an activity

Ex. Decide to buy a new game; decide what game to buy; decide where to buy it; get directions to store; go to store; enter store; find game in store; buy game; leave store; go home.

Designers observe and interview users for insights about their behavior more than their goals. The activity, not the people doing the activity, guides the design.

Pros: Gets designers to focus on the behavior of users

Cons: By fixating on tasks, designers won't look for solutions for the problem as a whole

3. Systems design

Focuses on the components of a system

Structured, rigorous design methodology

Uses an established arrangement of components to create design solutions

Users are de-emphasized in favor of context; focus on the whole context of use, not just individual objects or devices

Pros: eliminates guesswork and fuzziness of other approaches, provides a clear roadmap for designers to follow; useful for seeing the big picture, a holistic view of the project

Cons: rigorous and time-consuming

4. Genius design

Relies almost solely on the wisdom and experience of the designer to make design decisions

Designers use their best judgment as to what users want and then design the product based on that judgment

Apple computer does most of its design this way (e.g. iPod)

Best practiced by experienced designers

Pros: fast, easy, personal way to work; may allow designers to think more broadly and innovatively

Cons: may miss user needs and result in an un-usable product

Lessons from YouTube's success

I recently watched a video by Jawed Karim, the 3rd co-founder of YouTube. The video is called "YouTube: From concept to hypergrowth."

In the video, Jawed discusses his observations on why YouTube was successful. Some key points from the presentation are below.

There have been a handful of disruptive web2.0 applications over the years:

  • LiveJournal (1999): allowed easy use/creation of blogs
  • Hot or Not (2000): anyone can upload or download user-generated photo content; matched take-off of digital cameras.
  • Wikipedia (2001): large-scale social collaboration can achieve order. People are willing to donate their free time
  • Friendster (2003): not the first social network, but the first one to catch on. Not based on email addresses, so better. It commoditized social networking.
  • Del.icio.us (2003): Remote bookmarking, so you can access them from different computers. Popularized concept of tagging
  • Flickr (2004): Combined del.icio.us and photo sharing into a new product; before this, people shared photos within private networks; Flickr enabled people to share in public, using tags to search

When YouTube was started in early 2005, it was very difficult to watch, share, and discover videos on the Internet. The state of video viewing in 2004 was you went to a directory that listed a bunch of video files. You had no description or thumbnail for each one of those videos. You didn't know how these videos related to other videos. There was no way for people to connect over these videos. When you tried to download a video, you were forced to wait (buffering...) or had to download codecs, many of which didn't work for you. You couldn't see what was in the video until you downloaded it and started watching it. In other words, a very difficult experience.

So how did the site grow? When it was first launched in April 2005, nobody uploaded videos other than the founding team. They tried to email all their friends and get them to use it (which was the only marketing that HotorNot ever did). That didn't work. They put up a posting on Craiglist in LA to get cute girls to upload videos of themselves. They offered $100 to any cute girl that would upload 10 videos. That didn't work. They wrote to a bunch of reporters from Wired magazine asking for coverage. That didn't work. So what did they do?

They decided to revamp the site. They added a bunch of features to enable the product to promote itself.

1. Related videos: encouraged users to explore more videos on the site. Once they found a clip they liked, they could watch additional related clips

2. Easy sharing: made it extremely simple for users, with one click, to share videos with their friends. That way, their friends wouldn't get spammed by YouTube, but by their friends themselves.

3. Encouraged users' social interaction: find other users' favorites

4. Added external video player: allowed anyone to put a video on their site. This was probably the most popular feature. It extended YouTube's reach beyond its own site. Most notably, on MySpace.

The YouTube team noticed that every 2 weeks, there would be a "blockbuster" video that would drive a lot of traffic (thru sharing and WOM) to the site. As the usage grew, the frequency of these "blockbusters" increased to the point where it became multiple hits a day.

Another important lesson: YouTube let the community drive the site. They couldn't anticipate everything that the community wanted to do with the site. But they responded. For example, they created a feature that allowed people to post video responses (rather than just text comments) to videos.

Finally, they rewarded the users that made their project possible (similar to Threadless). They gave away an iPod every day in Nov. 2005 in order to stimulate video uploads.

3 phases of a start-up (2)

We met with Randy Komissar from Kleiner Perkins last week. He gave us a lot of valuable advice about the 3 phases of a start-up.

Phase 1: demonstrate the value
Phase 2: demonstrate options for scaling
Phase 3: execute

Phase 2: demonstrate options for scaling

If phase 1 was all about demonstrating the value proposition for a handful of customers, phase 2 is all about demonstrating that this value proposition can scale across many, many customers (or across multiple products with the same customers).

For any company, there are 2 ways it can scale: either you scale across customers, or you scale across products. To scale across customers, you would need to demonstrate that your product can be sold to multiple customer segments (e.g. geographies, vertical industries, etc.). You would need to establish reference customers in each target segment and build a pipeline of potential deals. To scale across products, you would need to show that your existing product has line extensions that appeal to your existing customers. In either case, you're still not necessarily generating a lot of revenue yet. But you're creating the perception that customers are lined up to buy from you.

In general, what are the "pre-conditions" of an opportunity that make it likely to scale?

1. Homogeneity of customer needs: If every sale requires custom development, the business will not scale easily. On the other hand, if customer needs transcend segment differences, it means that you should be able to scale across customers.

2. No special/scarce resources required to make or sell the product: I evaluated a start-up company in the semiconductor services space for acquisition by a larger company. The start-up provided a useful and valuable service to its customers. However, the service was so complex that it could only be sold by 2 of the company's employees (the CEO and CTO). These 2 people were the only ones who understood the service well enough to convince customers to buy. Needless to say, the company did not grow very quickly.

3. Platform that will accommodate product extensions: This is Google's strategy with building the "Googleplex"--the computing infrastructure that consists of a number of custom-built, self-aware computer clusters across the world. Google believes that its Googleplex will be the platform that enables rapid, low-cost deployment of applications to customers--a significant advantage over competitors who use off-the-shelf computing equipment. Of course, first Google needs to develop another "killer app" other than the search and Adwords platform. But, once they find the other killer app, the Googleplex will be the platform that enables product extensions.

3 Phases of a Start-up

We met with Randy Komissar from Kleiner Perkins last week. He gave us a lot of valuable advice about the 3 phases of a start-up.
  • Phase 1: demonstrate the value
  • Phase 2: demonstrate options for scaling
  • Phase 3: execute
Phase 1: demonstrate the value

In this phase, the start-up is trying to show investors that it has developed something valuable to customers. This phase is marked by a set of iterative tests designed to support or refute hypotheses about the business. Suppose I have an idea for a new business. That idea is really a hypothesis--that whatever I develop will be valuable to customers. I should come up with a prototype that I can begin testing with customers to validate that hypothesis.

The name of the game in this phase is to learn by getting real customer feedback as early and as often as possible. I run a series of iterative experiments where I test my hypotheses with customers. Each time I learn something from a customer, I should refine and tune my hypotheses. And my "business experiment" should be designed such that I am testing the core, fundamental elements of my new business idea as early as possible. That way, I learn early whether my idea, at its core, actually has value or is simply a waste of time. Over time, I can get into testing details of the idea (such as specific product features).

It matters less whether my hypotheses are right or wrong. What's more important is that I have hypotheses, and that I have the strength of character to accept real world feedback that supports--or refutes--my hypotheses. I want to fail early, fail often, and most importantly, fail inexpensively. Failure at this stage is really good. It means I've learned something and probably avoided costs. I want the feedback from customers that they dislike a planned product feature well before I sink costs into actually developing that feature.

You should strive to test your hypotheses in a "smart" way. You should brainstorm a list of potential hypotheses, and test them in order of likely success. This requires judgment, of course, but you can improve your chances of having good judgment by synthesizing input from experts and customers. By testing them in order of likely success (rather than randomly), you improve your chances of hitting on the right solution early (without burning through too many iterations, too much time, and too much money).

During this phase, I have the challenge of doing as many iterative experiments as possible, and tuning the hypotheses of my start-up idea, as cheaply as possible. That means that I should always be thinking, "What's the cheapest way for me to get the feedback that will tell me whether my hypothesis is right or wrong?" So I should defer committing resources--which means deferring hiring people and even building the product--until I know whether the hypothesis justifies the commitment of those resources. Try to engage potential employees on a contract basis rather than commit to hiring them during this phase. Build very lightweight prototypes of products to test with customers, until you've gotten feedback that justifies the commitment of development time and resources to the product.

You sort of know when you're ready to exit this phase of start-up development. You've been testing and iterating your product idea with multiple customers. You've now developed a pretty valuable prototype or product, and gotten a handful of customers very excited about your new product idea. You may have engaged a couple of customers to participate in a trial with your product. You haen't really generated significant revenue yet--in fact, you may not have any revenue at all. But you have some excited reference customers. Will blog about Phase 2 next time.

Musings from 37 Signals

I've been reading the online book Getting Real by 37 signals. It's a quick, easy read and it contains a lot of interesting lessons about product development in the new web 2.0 world. Here are some of the interesting take-aways:

1. Keep yourself as agile as possible so that you can adapt to the external environment quickly.

That means don't build too much into your product. Don't commit resources unless you must. Fail early, fail often, fail inexpensively. Failure in a startup is the only way you'll learn. You've got to keep your costs to change very low. Being small provides you an advantage over larger competitors--you are more nimble, you can change much more quickly.

"Less mass lets you change direction quickly. You can react and evolve. You can focus on the good ideas and drop the bad ones. You can listen and respond to your customers. You can integrate new technologies now instead of later."

"Nimble, agile, less-mass businesses can quickly change their entire business model, product, feature set, and marketing message. They can make mistakes and fix them quickly. They can change their priorities, product mix, and focus. And, most importantly, they can change their minds."

"Change is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead."

"What might take a big team in a huge organization weeks to change may only take a day in a small, lean organization. That advantage is priceless. Cheap and fast changes are small's secret weapon."

The book discusses the concept of emergence--"unforseen occurrence." Emergence requires the lack of complex rules.

"The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence. Keep it small. Keep it simple. Let it happen."

2. Constraints (lack of time, money, people) are good.

Constraints drive innovation ("Necessity is the mother of invention"), force you to clarify your priorities and focus on the most important things. Similarly, 37 Signals advises us to flex scope, but not time or budget. Getting something out the door--even if it's not everything that we want--is better than being perpetually in development.

3. Keep the product simple.

Every feature added has a price. Make new features prove their value before being added.

4. Use an iterative development approach.

"Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again."

"Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you'll get an active app up and running quicker since you're not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention."

"You don't need to aim for perfection on the first try if you know it's just going to be done again later anyway. Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly."

5. Hire less, hire later, and try people out before you commit to hiring them.

You would be surprised with how much you can get done with fewer people. "Whenever Jack Welch, former ceo of ge, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position."

"A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time."

Kick the tires before you commit to bringing someone on. "Work with prospective employees on a test-first basis. It's one thing to look at a portfolio, resume, code example, or previous work. It's another thing to actually work with someone. Whenever possible, take potential new team members out for a 'test drive.'"

Monday, May 14, 2007

Don't Make Me Think (4) - Home page

  • According to Krug, there are several things that a homepage must accommodate:

1. Site identity and mission (homepage must tell me what site this is and what it's for)

2. Site hierarchy (overview of what the site has to offer, including content--"What can I find here?"--and features--"What can I do here")

3. Search (most sites need to have prominently displayed search box on homepage)

4. Content promos (spotlight the newest, best, or most popular pieces of content, like top stories and hot deals)

5. Feature promos (invite me to explore additional sections of the site or try out new features)

6. Timely content (if site depends on me coming back often, home page needs to have content that gets updated frequently)

7. Short cuts (most frequently requested pieces of content may deserve their own links)

8. Registration (links for new users to register, old ones to sign in, and welcome message if I'm already signed in)

See the example of YouTube's homepage:

Don't Make Me Think (3) - The Trunk Test

Another cool idea from Steve Krug's book: The Trunk Test.

"Imagine that you've been blindfolded and locked in the trunk of a car, then driven around for a while and dumped on a page somewhere deep in the bowels of a Web site. If the page is well designed, when your vision clears you should be able to answer these questions without hesitation: What site is this? (Site ID) What page am I on? (Page name) What are the major sections of this site? (Sections) What are my options at this level? (Local navigation) Where am I in the scheme of things? ('You are here' indicators--breadcrumbs) How can I search? (Search)"

1. Choose a page anywhere in the site at random, and print it.

2. Hold it at arm's length or squint so you can't really study it closely.

3. As quickly as possible, try to find and circle the following:

  • Site ID
  • Page name
  • Sections
  • Local navigation
  • "You are here" indicators
  • Search

Sunday, May 13, 2007

Don't Make Me Think (2)

Still reading from "Don't Make Me Think." The chapter I'm reading now, called "Street Signs and Breadcrumbs," discusses some of the conventions that websites use to improve usability.

One convention is the use of persistent navigation to tell the user where he (or she) is in the website. There are 5 things that belong in every site's persistent navigation:

1. Site ID

2. A way home

3. A way to search

4. Utilities

5. Sections

See the home page from Flickr--shows each of these elements in practice.

Sections are the primary navigation of the site. The top level of the site's hierarchy.

Following is a glance from YouTube, shows 4 out of 5 elements:

Some consumer media lessons

Over the past 2 months, I've spend some time with experts from the consumer media industry, including folks who have done programming at MTV, Discovery Channel, F/X, etc. Here are some of the lessons I have learned from spending time with these experts:

  • You have to be relevant. Relevance comes from making things "local" in space and time.
  • You can present a national or international news story, but it's more relevant if you can tell me how it affects me or my community (or even makes me think about how it affects me/my community).
  • You've got to present current information, create the perception that things are "live," that this is happening now. If you can do that, you're raised the urgency and you can get me to pay more attention. Many tricks for doing that: put the date and time, show a ticking clock, show feeds/crawls of information.
  • Don't just re-broadcast content that's already available elsewhere. Consumers will seek you out if you provide compelling content that they can't find anywhere else.
  • In addition to original content, media organizations can provide value with editorial role--if you get syndicated content, filter it, package it, put your spin on it, do something to make it yours (and different from what people can get elsewhere).
  • Consumers like lists. Give me the top 5 or top 10 things to do.
  • Everything you present has to have some value for the consumer to get them to pay attention. Even branding/interstitials can and should be used as content (e.g. MTV).

More to follow...

Netflix, Google, and fast iterations

Another interesting post at UIE: http://www.uie.com/articles/fast_iterations/

"We make a lot of this stuff up as we go along," the lead designer said. Everyone in the group laughed until he continued, "I'm serious. We don't assume anything works and we don't like to make predictions without real-world tests. Predictions color our thinking. So, we continually make this up as we go along, keeping what works and throwing away what doesn't. We've found that about 90% of it doesn't work." - Lead designer, Netflix

"In the case of the Toolbar Beta, several of the key features (custom buttons, shared bookmarks) were prototyped in less than a week. In fact, during the brainstorming phase, we tried out about five times as many key features -- many of which we discarded after a week of prototyping. Since only 1 in every 5 to 10 ideas work out, the strategy of constraining how quickly ideas must be proven allows us to try out more ideas faster, increasing our odds of success." - Marissa Mayer, Google

Fast prototyping, getting real user reactions--these are the hallmarks of Netflix and Google's design approaches.

The benefits of fast iteration:
  • Fail fast--don't waste time on things that won't work
  • More experimentation--try out a wider range of things
  • Fact-based--let real user data/reactions to prototypes, rather than opinions/arguments, guide the decision-making
  • Create customer loyalty--users feel that they are co-creating the product when they see rapid iterations, lots of things being tried with their input

5-second test

Here is an idea to test whether people quickly understand what your website is about. See the full article at http://www.uie.com/articles/five_second_test/:

Show users a full content page for 5 seconds to get their initial impressions
1. Show users a content page. Once the users views it for 5 seconds, cover it up or change the window
2. Ask them to write down everything they can remember about the page
3. Ask them questions like, "What is the most important information on this page?" or "How would you go about completing task XYZ?"

You can understand how clear/concise your page was, whether users understood the primary purpose of the page, whether users recalled the critical information, etc.

The 5-second test can be done quickly/cheaply using paper prototypes, however, it's best for pages where there's a single primary purpose (rather than a homepage, where there might be multiple purposes).

Don't Make Me Think (1)

I've started reading a new book about website usability: "Don't Make Me Think" by Steve Krug.

The book discusses how to optimize website design to enable users to breeze through the navigation, without having to think. Here are some of the good lessons/take-aways from the book:

1. When you're creating a website, your job is to get rid of the questions that users face when they look at a page. ("Where should I start? Why did they call it that? Can I click on that? Why did they put there there? What is this?") Everything should be obvious to the user--what the site's purpose is, what they should do, etc.

2. People don't usually read web pages--they scan them. They tend to focus on words and phrases that seem to match the task at hand, or their current/ongoing personal interests. There are some trigger words that are hardwired, such as "sex," "sale," "free," and our own name.

3. Design pages for scanning by following 4 simple rules:

  • Create a clear visual hierarchy on each page: the more important something is, the more prominent it is; things that are related logically are related visually; things are "nested" visually to show what's part of what
  • Break up pages into clearly defined areas: glancing around, users should be able to tell, "Things I can do on this site! Links to today's top stories! Products this company sells! Navigation to the rest of the site!"
  • Make it obvious what's clickable
  • Keep the noise down to a dull roar: eschew business and background noise; simplicity is good

4. Get rid of half of the words on each page, then get rid of half of what's left.