- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
New Years Resolution
I had a recent experience which helped emphasize how important it is to see things within the context of the user's environment. In this instance, I'm speaking of buying a new TV. Our "old" TV had served us well, was a high-def projection model, but with prices falling and screens getting brighter and flatter, I was able to convince the wife it was a fairly cheap midlife crisis purchase after all. But which to buy? Brand and reputation aside, the differentiating factor between sets were size, display type and resolution. If you haven't been pouring over spec sheets lately, the main idea is that there are two display types - Plasma and LCD and two main resolutions 720p and 1080p. For size, I wanted bigger or same as my other model so I wanted 47", 50" or 52". In my usually thorough fashion, I poured over different websites and user opinions and ended up buying the cheapest one that fit the bill... a 47 inch 1080p LCD.
The reality of setting this thing up turned out to be a fairly educational experience, all my time staring at rows of displays at Best Buy or Costco or reading Consumer Reports gave me a vague idea what were some good qualities to look for. But much like talking about what a user wants it didn't prepare me for what the real user experience difference there was between the resolutions and sizes. I really ended up finding out what all the jargon meant only when presented with the device in my own environment. It reminded me of a project where all the developers had 1680x1050 resolution monitors and the users had 1020x800 laptops. It was too tough to get the developers to realize that the way they displayed the app was removing some of the problems like cropping of text, the addition of scrolling to content, and other display problems they just weren't seeing because of their screen size. The solution I presented was to open the application in the specified fixed resolution (1000x780 or so). My point being that if they shared the pain with the users, we could build a better app, but high resolution is hard to give up, and they secretly went back to opening it full screen.
Setting up the TV I was unprepared for how vibrant the colors, and how sharp the picture, especially the high definition picture broadcast here in Chicago. There are definite advantages to higher resolution that 1080p provides (near 2 million pixels), but I noticed that as I moved backward, the screen became 'smaller' and the higher pixel count less noticeable. In all the reviews I had read, they focused mostly on comparing black levels and picture contrast, but never talked about how distance really effects the way you perceive detail, this article at cartonbale.com describes it well. 
As I sat further back I became more and more convinced that a bigger TV was necessary, I just wasn't seeing the benefits, so I traded it in for a lower resolution 720p model at 50" for the same price.
The new model was certainly the right size, but now all I could see was the lack of fine detail, of course as I moved back, it looked fine, even better than before since the TV was noticeably larger. But I couldn't get over the feeling of something missing. A decent relationship with the pythagorean theorem helped (TV's are measured diagonally for some reason) determine mathematically what I was perceiving but couldn't find on spec sheets or by comparing screens next to each other at Best Buy. For purposes of this article I found this calculator will help you out with the math.
The iphone has a great screen - 160 pixels per inch and distance between dots is .15 mm which means it really goes right up to inches from your eye.
Display monitors like the 22 inch that we use on our computer - 90 pixels per inch - distance between dots .28mm - we can determine that closeup viewing within 1 foot looks good.
The first set - 1080p 47" set was 46 pixels per inchand a whopping .54mm between dots, still, closeup viewing even within 5 feet doesn't reveal the gaps.
The 720p 50 inch plasma set was 29 pixels per inch with a chasm of .86 mm between the dots, still, I don't know if it's the dots or the gaps or what, but with this display showing a mere 1 million pixels, it certainly seemed less detailed.
Or to put it more succinctly (courtesy of some forum post found at avsforum.com:
The human eye can resolve 300 dots per inch at 1 foot. The value is linearly scaleable. In other word 30 dots per inch at 10 feet. A 50 inch diagonal tv has a Horizontal width of 50 x .87= 43.5 inches. 1080 displays have 1920 horizontal pixels. 1920/43.5= 44.37 pixels per inch a 720 display would have 1280 /43.5=29.42 pixels per inch. A person with 20:20 vision can only resolve 30 dots per inch at 10 feet. Thus at 10 feet both 720 and 1080 displays should look identical . However as we get closer to the screen the 1080 display would start to look sharper. At about 8 feet the 1080 would really start to shine.
Removing all the picky bits about LCD vs plasma, setup, color temperatures and such, the lesson learned was even with the science involved, the main way to pick a TV is where you are going to put it and watch it. While a little part of me wants to upgrade to the 1080p set at 50inches, the extra money may not be that well spent considering my distance from the screen. So next time you're at the showroom, ask them what their return policy is, trying it at home is the only way to find out.
Topics: User Research
Chaos and Order
The process of designing (guis/websites/apps what have you) can be very exciting, and ultimately, when a design goes well and achieves its purpose, it can be highly rewarding. But it's also a challenge. Every designer has their own set of struggles that they go through during the design process.
One of the things I struggle with most as a designer is the urge I have to make things consistent, or symmetrical. I prefer order over chaos, I'll admit. I constantly have to catch myself from spending too much physical and mental energy on removing what I see as chaos, and replacing it with structure, consistency, balance and symmetry. It's not that these aren't worthy goals, but my experience is that sometimes those characteristics aren't the key, or even an important element on a particular interface screen or widget. In fact, in many instances I have found that what I consider order is quite an undesirable solution, or at least, not what the doctor ordered.
By instinct I look at my work through a designer’s lens. It is a macro view. I see the overall structure of the interface. I slave over task flows and wireframes, structuring them and fine tuning them so they please my aesthetic and philosophical sensibilities. I judge them by their adherence to my design rules-symmetry, balance, structure, consistency.
But for the judges that matter, the users, the interface is simply a tool that they will use to accomplish a task (or set of tasks). They will judge its success not by any theoretical characteristics, but by how well it allows them to accomplish those tasks. They won’t look at the blue prints. They’ll never get a look at the task flows generated in the design process, nor would they have any desire to.
Internalizing this distinction--the difference between my view, and the user’s view--and embedding it into my design process is one of the challenges I face, and one of the determinants of a successful design.
Powered by ScribeFire.
Topics: Design, Design Patterns, User Research
Design? Meet Research.
A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.
But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it? A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.
Topics: Accessibility, Design, Usability, User Research
Why User Research Matters
What if you brought in users to test your application and the final result was one big collective yawn. It’s not that the product wasn’t usable -- oh, maybe some minor tweaks to the presentation layer could improve things, but overall all tasks were completed fairly well. No, it’s more that the users had no desire to use your product because, well, because quite frankly it didn’t answer their needs. In short, the proposition was wrong from the very beginning.
To steal a quote from disambiguity: "If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product."
I know it sounds fundamental, but the fact is that the value proposition you’re offering needs to solve real problems for real users. Concepts are great and brainstorming is fun, but if the user is not an integral part from the very beginning, they may decide they don’t want any part of the result.
The good news is that the value proposition can easily be validated by conducting user research early on in the project cycle. Talk to the people you’re designing for, understand their needs and check to see whether or not your ideas and concepts are on the same page with their goals.
Usability starts at the very beginning, with user research. For a minimal amount of time invested at the start of a project, you’ll save yourself a lot of wasted time wandering down the path of functionality that solves the wrong problems or even worse, is not even wanted by the users.
Topics: User Research
Ideas for User Research
User Research isn't limited to sitting behind a glass window, nervously chomping on M&Ms while glaring at the hapless user who’s attempting to navigate through your next killer app. There are different types of user research that can be incorporated throughout the lifecycle of a project, often at minimal costs to the company but with maximum results towards a more usable product.
User research methodologies generally fall into the two broad categories of Qualitative (why is something happening) and Quantitative (what is happening). With Qualitative research, you use a small sample size to discover new insights which can then be tested or proven. Quantitative research uses a large sample size to test or prove something, perhaps one of the insights you uncovered during your qualitative research or to determine the primary browsers you want to support.
Starting with Quantitative Research, here are some methods you should consider incorporating into your next project:
User Surveys uncover what the users say. You’ll get a large sample of responses on your users’ goals, behaviors and attitudes (assuming you have a well-designed survey of course). Surveys allow you to easily gather data on almost any topic and the results can then be ranked and assigned a priority for future design, scoping, etc..
Site Traffic Analysis tells you what your users do. An analytics tool's output tell you how your site is navigated, which pages are abandoned, which content performs well, which browsers you users are actually using, and so on. Your logs files will tell you some of this information as well, but slog through those files just once and you’ll soon realize the value of an analytics tool.
Information from these Quantitative research methods will tell you what is happening but not necessarily why it’s happening. For that, you’ll need to conduct some sort of Qualitative research, such as:
User Interviews let you learn about your users. Either from talking to a person face-to-face or over the phone, interviews yield detailed information about your users’ goals, behaviors and attitudes. They are usually better when conducted one on one rather than in a group because you can remain focused on that one individual and what they're saying. Keep in mind that loosely constructed conversations, rather than a formal script, allow for unexpected tangents that can lead to surprises and insights.
From Field Studies, you’ll gain context about where and how and when people actually use your software (or the competition) as you observe them in their daily routines. From this direct observation, you’ll also gain an understanding of your user’s attitudes and perceptions which will help in designing the user experience.
Usability Testing is done to observe user behavior. It is different from a field study in that you’re not merely observing the users' actions, but you’re also directing their actions. It lets you watch how people use your application to perform specific tasks and where they encounter obstacles, which features slowed them down, which elements were confusing, etc. Usability Testing yields a richer quality and quantity of information than a survey.
Topics: Usability Testing, User Research
Research and the Physical Environment
It’s important to understand the physical environment of the user when designing any kind of a product. To do so, there are some key questions to ask and things to observe:
- Lighting – Is the user in good light, poor light, outdoors or indoors?
- Work area – How large is the workspace? A desk or counter is different than a hand-held device without a table or ledge to rest the device on
- Screen size – How large is the typical screen (for software) and what is the resolution?
- Distance – How far apart are users that may need to collaborate?
- Variability – Does the environment change, or is it consistent?
- Distractions – Are there events in the environment that may prove distracting to the user or interrupt the process?
Asking such questions should be a key part of research, but even better is to photograph or create a simple illustration of the user’s environment.
Topics: User Research
A Short List for Contextual Inquiry
In its unscientific form, contextual inquiry is simply observing people do what they do. As professionals, however, we can be more effective by applying some science to the approach.
In a nutshell, the following items are recommended for a good contextual inquiry.
1. Understand your audience - do some research on what they do, what their tasks and goals are, and the unique characteristics of the environment in which you will observe them.
2. Make a list of what you want to observe - time with users is usually a precious commodity, so make a wish list of what you would like to get out of the session.
3. Plan a technique for getting rapport - Beyer and Holtzblatt (see reference below) identify several approaches such as the Master/Apprentice. In this approach, you are the apprentice observing the master at work.
4. Define all of your measuring and recording techniques in advance - you may wish to use audio, photography, video, etc., but even for simple note taking you may wish to prepare note sheets in advance to make the best records possible. For example, a "swim lanes" note sheet can be used to record the interactions between what the user is doing vs. what the system or tool is doing.
For more in depth information, you can look to two very good books. The first is Beyer and Holtzblatt's Contextual Design: Defining Customer-Centered Systems. The second is Mike Kuniavsky's Observing the User Experience.
Topics: Best Practices, Ethnographic Research, User Research
Unanswered Questions of User Research
Luckily, formal usability testing offers us the opportunity of conducting a near-scientific study of stimulus and response. We're able to cull prospective users from a pool of particpants, and screen them against a carefully chosen list of attributes, including gender, age, computer literacy, and other specific qualifications--much more discrimination than the "real world" of users and links and happenstance allows.
When it comes to initial requirements gathering, though, we often (in the words of Tennessee Williams), "depend upon the kindness of strangers." There are at least three types of early user researh/requirements gathering whose success often depends upon the enthusiasm or engagement of the client. It follows that this pool of resources must be evaluated through the filter of operative agendas. Here are three examples of user research that can be potentially valuable if all factors are considered.
1. Subject matter experts - an incredibly valuable asset for building site or application content. Always keep in mind that the SME's time is constrained. Keep your questions open-ended, but focused on the task.
2. Stakeholder interviews - keep in mind that the client probably has an incentive to obtain "buy in" with these interviews. While much independent data can be garnered from these interviews, pay close attention to the client's needs and goals with these interviews.
3. "User" interviews - at an early stage in the project, these people are probably anticipated or target users. Don't lose track of capturing data to build personas and actual user scenarios.
Topics: Requirements, User Research
Breaking the First Commandment
The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this. UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)
If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically:
Know thy users, and thy users are not thyself
It's a good guideline, of course: as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.
But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.
And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive: after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.
To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.
Learning Complex Domains for User Experience Design (UXD) Projects
Legend has it the famous advertising slogan “Two scoops of raisins in Kellogg’s Raisin Bran” was created by an energetic copywriter who literally dumped out the box of cereal on a table and scrutinized the content for inspiration. Moral of the story: As designers we have to know our product. But what do you do when your product involves biological science, electrical engineering or any other complex domain? Here’s a few suggestions for getting up to speed in a complex subject areas.
Speak the Language
First, you have to speak the language. Ask your subject expert to outline the top ten or fifteen words or expressions used on a daily basis by your users. Then have him or her define those words in terms that you can understand. Keep the number of words to ten or fifteen, and only the most important terms.
Key Scenarios
Next, identify the top five or so key scenarios your users do in a typical day. Each scenario should have a simple title and a set of steps. Remember, the goal initially isn’t to do user research, but just to get a feel for what people are doing. Try to cover the five scenarios in an hour or less. This will help your expert from getting too bogged down in details you won’t be able to digest yet.
Map the Scenarios
Once you have the key scenarios, arrange them in a hierarchy. Of course, it’s possible the scenarios are isolated tasks and don’t fit a hierarchy, which is fine. But usually a hierarchy of some kind applies. This hierarchy will become a context for understanding when your user does various things.
Construct a Day in the Life Narrative
To test your understanding of the domain, take the information you have gathered and construct a day in the life narrative of your user. In doing so, you will create a vehicle for refining your domain knowledge and a start to your more serious user research.
Two Hours or Less
No matter how complex the domain, make it your objective to get through the above tasks in 2 hours or less. By time limiting the exercise, you can keep your subject matter expert from straying into the details before you have the basics solidified.
About Pathfinder
Recent
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
- TankEngine: New plugin for Rails iPhone Development
- Symphony of Ruby on Rails and Flex through RubyAMF
Archives
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
Restlet
RETE
Review
Rich Interactions
ruby
rubyamf
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
work life balance
XML
XML Metadata
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZK