pedro cubillo :: pedro.cubillo@gmail.com
Throughout the years I have observed and interviewed hundreds of users, whether at the corporate or consumer levels. All have very different objectives but share one crucial commonality when it comes to interaction design: they all have objectives to meet and tasks to complete in order to meet those objectives. Objectives and sub-tasks
Understanding objectives and the sub-tasks that meet those objectives is, arguably, the number one goal in interaction design. Users’ intents vary depending on context. In a computer game, a goal may be to reach the next level in the game, or to conquer a territory, or to defeat an opponent to earn stronger, more efficient weapons, for example. In interactive television, it may be to find a good program to watch, while in a corporate application, the goal may be to save processing time by automating certain work flows. How to understand objectives? There are many research methods, with ample bibliography on the web. Depending on each project, a different method may be employed but, as a general rule, observing users while they conduct their tasks is almost required in interaction design. Surveys, interviews, lab usability studies and the sort tend to provide good information but leave out an important aspect: context. Is the person conducting the task in stressful conditions, or in the comfort of their home, or driving? Formal task analysis may be found in GOMS, an approach to understanding goals and breaking down tasks. I briefly describe the Model Human Processor, the foundation of GOMS in the section cognition.
You can do
In my experience, I have heard this very phrase from roughly 95% of the users I have interviewed. “I like it because you can do this or you can do that.” It is the ability to do something what gives users the control they innately demand from any system. User control is the number one design rule and many of the frustrations come when this rule is not properly applied. Put differently, frustrations come when users can’t complete a task that will get them closer to their objectives.
A product must solve a problem.
We bombard users with new things to do. Still today there's poor usability in many products. Name the elements of trust. Products need to build trust. Tasks have sub-tasks. Try to remove some. Perceive, understand, use, modify, expand. This is the cycle. Online maps are great. But, do they solve the problem? Meet the user. Talk to a hundred people about the same topic. Draw your conclusions. Solve the problem. Define fun. What is the product telling me? If I see ten elements, I process ten elements. If I see a hundred elements, then I have to process a hundred. Design rules are there for a reason. Humans are complex beings. Simplify. If there is an error message, there is and error in the design. I hate bold. Not always. What are the pieces of the puzzle? Roughly, the business, the user, the advertiser, the content provider, the interface. Each has objectives, often different. Design is not easy. Meet them all and you'll find the where they all meet. Get to know the habitat. Get evidence, not opinions. Products change. The process remains: observe, learn, identify, solve, create, enable, distribute, verify. There's always version two. There should always be a version two. What makes something difficult? Can goals be adapted to the product? Should they? Can we design to manipulate goals? Connect people, enable communication of messages, feelings and we have new goals. So maybe the answer is yes. What matters? Speed, visual, emotional, learnability, size, cost, feasibility, functionality, safety, usability, efficiency, security, compatibility, acceptability, effectiveness. Scale each from one to ten. What's your variable? Grow novices into experts. Find out for yourself. Speak the user's language. Which user? The expert who knows the language, or the novice who doesn't? Learnability. Iterate. Or compare. Or both. Habituation. Continuity. Comfort. Avoid change. Evolve. Remove dialogs. Let the design speak. Eliminate errors. In particular those that do not look like errors. Visibility: it's either there or not. Grouping is used to manage complexity. User control. People want to feel in control of the car. That makes sense. Icons. Don't. With text? Fine. Kitchen sink design. Backpack design. Feedback. Don't tell me you did it. Show me you did it. Work on the data itself. Bridge the gap between intention and functionality. Color: to categorize, differentiate or highlight. Don't be afraid of white space. Just one more tool. Never enable loss of work. The user is not a designer. Everybody is a designer. Personalization. Comes and goes. Or rather, it came, left and is now back. Beware. Stay focused on what you need to stay focused. Know your risks. Customization. Not part of my task. This one is big. I could go on and on. There is evil. Everything else, for the most part, is fine, including Agile. There's too much of it. Focus on the work and not on the methodology.
We bombard users with new things to do. Still today there's poor usability in many products. Name the elements of trust. Products need to build trust. Tasks have sub-tasks. Try to remove some. Perceive, understand, use, modify, expand. This is the cycle. Online maps are great. But, do they solve the problem? Meet the user. Talk to a hundred people about the same topic. Draw your conclusions. Solve the problem. Define fun. What is the product telling me? If I see ten elements, I process ten elements. If I see a hundred elements, then I have to process a hundred. Design rules are there for a reason. Humans are complex beings. Simplify. If there is an error message, there is and error in the design. I hate bold. Not always. What are the pieces of the puzzle? Roughly, the business, the user, the advertiser, the content provider, the interface. Each has objectives, often different. Design is not easy. Meet them all and you'll find the where they all meet. Get to know the habitat. Get evidence, not opinions. Products change. The process remains: observe, learn, identify, solve, create, enable, distribute, verify. There's always version two. There should always be a version two. What makes something difficult? Can goals be adapted to the product? Should they? Can we design to manipulate goals? Connect people, enable communication of messages, feelings and we have new goals. So maybe the answer is yes. What matters? Speed, visual, emotional, learnability, size, cost, feasibility, functionality, safety, usability, efficiency, security, compatibility, acceptability, effectiveness. Scale each from one to ten. What's your variable? Grow novices into experts. Find out for yourself. Speak the user's language. Which user? The expert who knows the language, or the novice who doesn't? Learnability. Iterate. Or compare. Or both. Habituation. Continuity. Comfort. Avoid change. Evolve. Remove dialogs. Let the design speak. Eliminate errors. In particular those that do not look like errors. Visibility: it's either there or not. Grouping is used to manage complexity. User control. People want to feel in control of the car. That makes sense. Icons. Don't. With text? Fine. Kitchen sink design. Backpack design. Feedback. Don't tell me you did it. Show me you did it. Work on the data itself. Bridge the gap between intention and functionality. Color: to categorize, differentiate or highlight. Don't be afraid of white space. Just one more tool. Never enable loss of work. The user is not a designer. Everybody is a designer. Personalization. Comes and goes. Or rather, it came, left and is now back. Beware. Stay focused on what you need to stay focused. Know your risks. Customization. Not part of my task. This one is big. I could go on and on. There is evil. Everything else, for the most part, is fine, including Agile. There's too much of it. Focus on the work and not on the methodology.
Elements of cognition important in interaction design.
| Model Human Processor | Perceive, understand, react. Card, Moran and Newell present us with a human computer interaction model, coined the Model Human Processor. This model describes three processors with which humans perceive, process and react to external stimuli. First, the perceptive processor receives information from the world through the visual, auditory or tactile systems. The information is then processed by the cognitive processor to turn the stimulus into something we understand. The motor processor comes in last to execute the order that responds to the stimulus. All of this processing and acting upon stimuli takes time. You can only read so fast, you can only understand at a given rate and you can only move the mouse to a target and click it at a given rate. While not every design project requires in-depth understanding of the model human processor, or any theory of cognition for that matter, it is important, at least, to have a basic understanding of information processing, including the structure of memory and how information is stored and retrieved. Arguably the best work in the field of Human Computer Interaction, to date. |
| The Seven Stages of the Action | Define intent, execute, evaluate. Don Norman presents us, in his Design of Everyday Things, with the seven stages of the action. This model is not far from information retrieval models extensively studied in the classic IR field. The seven stages of the action may be grouped into three higher level categories: define an objective, execute the action and evaluate the action. |
| Information retrieval | How people search. Of course, the topic is worthy of an entire wikipedia of its own (all of the topics here are). Questions I would like to explore:
|
| Orientation and Wayfinding | Knowing where we are. We live in a 3d world. Some would argue there are more d’s, but that’s fine. A basic requirement to feel comfortable is to know where we are. Put this way, it seems a trivial thing. Getting to that point, getting to «know where we are» is not as trivial as it may seem. It takes time and practice, it takes learning a number of things, often the hard way. The most crucial: landmarks. The second: connecting landmarks to build paths from point A to point B. Do online maps consider this? They don’t even allow you to plot point B, or C or D. Research I conducted in this space clearly showed users begging (screaming) for this ability. The only way to do this nowadays is to use driving directions, which only allow you to do two points, not more. The only mapping tool that gets it more or less right is Yahoo’s Maps Beta. I spoke with Paulien Strijland at CHI in 2006 (from Yahoo’s UE team) about their findings and mine and there were not many differences including how surprising it was for us to realize that users were not screaming for complex mapping features and services. Much to the contrary. Among others, we did find how important it is for people to plot multiple locations on a map, and to make comments on them, and to get driving directions changing the order of destinations, and printing and... one more thing: nobody ask for more advertising. I talk about how I got to my design in the Maps page. |
| The Magical Number Seven, Plus or Minus Two |
This is the number of items we can store in memory for a given period of time. The time is generally milliseconds, and the items are referred to as ‘chunks’. Specifically, it refers to working memory. When we receive a set of chunks, and these could be sensory as well, not just verbal, we can retain the information for a given amount of time. After a short period of time, we begin to lose the ability to retain the information, a process called ‘decay.’ The are differences in time decay, based upon whether the information is verbal or sensory (e.g., auditory).
This finding is attributed to George Miller, who analyzed people‘s ability to retain information and presented his findings in 1956. However, research in this area has continued and new findings show that, while Miller’s conclusions remain accurate, working memory’s ability to retain information varies (somewhat) widely between populations and between data types. |
| Emotion | Connecting people. I don’t think people like isolation. In certain instances it is even a form of punishment or even torture. We humans, on the other hand, like to pile up in cities to feel «involved», feel a part of the whole. Many products and services succeed without requiring the need for many people. [Under the assumption that technologies are there to deliver as expected] Products that succeed are mostly products that involve more than one individual somehow. This is not to say that certain activities done in isolation are worse in any way. The iPod, for instance, may very well be seen as a product used in isolation (arguably) and as of 1Q 2006 it holds around 70% of the portable music device market. Take email, for example. Besides cheap and faster than prior methods, it succeeds because it connects people. Chat rooms. Blogs. Cell phones, regular phones, the web even. Not gaming. Online gaming. Roller coasters are fun, but they are more fun if you go with family and friends. This was supposed to be a «future topic». |
| Trust | How do we build trust? What has to happen for you to trust a person? What about a computer? Would you trust a computer? Who would you listen to, your best friend or closest family member? Or would you, instead, follow a computer’s recommendation? This is, arguably, one of the most difficult aspects of any Personalization effort. |
Agile is not new, but it is becoming fashionable.
Agile is a weapon. If it falls in the wrong hands, we are in trouble.
Agile is egocentric. There is too much focus on the methodology and much less on the work itself.
Agile is very strict, structured and unflexible.
What follows is simply to say that that the nature of the methodology, and why not mention it, the fact that for many of us is a new thing, will force millions of employees across the country to be focused on the methodology and how to properly adopt it. "Make sure you comply with the methodology... or You can't use requirements because we are moving away from waterfall... or I am now in three scrum teams and don't have time for the actual work... or Do you have any obstacles? Yes, too many meetings." These are actual quotes I hear every day in the office. I have never in my live, never, seen a less efficient work structure. Like everything else, how you implement it will guide your [level of] success.
The amount of time that teams spend in meetings is overwhelming. All of this if you are in a scrum team. Now imagine if you were in two.
Let me just clarify for those who may be unfamiliar with the methodology. Agile is a project management methodology (now) extensively used in software development. The methodology establishes teams, known as scrum teams, that work together across projects. Scrum teams work in thirty day periods. Whatever you can get done in thirty days is what gets published. A thirty day period is referred to as a sprint. Agile aims to break from the dependency on requirements documents and pushes away from the Waterfall methodology. This is my second major problem.
I agree that nobody is going to read two-hundred page documents full of software development requirements, much less follow them. Let me share my experience with my first 'requirements-free' application design project.
In December of 2005 we form the first scrum team in the company. We officially form the UI scrum team with myself as UI designer, a set of developers with expertise in the various angles of large application design and, of course, product owners, QA personnel, etc.
The first wrong turn takes place when we decide to dismiss, ignore, or some word of similar characteristics, a document containing feature definitions, use cases, feature flows and pretty much everything the team needed to know about the project. I can't really give many more details here, but the bottom line is that the entire infrastructure for the project was contemplated in the document. Of course, I complain about this because I wrote the feature specification based on extensive user research. Anyhow, the document gets ignored, the developers are ready to start coding and the unthinkable happens.
- What do we build?
- Well, we already discussed the features, replied the project owner.
- I know, but how do you want them built?
- Well, talk to the designer (me), responded the project owner declining any responsibility.
- Yes, I replied. It is all reflected in the feature definition which I distributed several weeks ago.
- I understand, but we are no longer following the waterfall approach, so we do not rely on requirements any more —responded one of the developers.
- I see, so what are you planning on building and how? I prompted.
- Well, you are the designer... the developer replied.
As you can see, the conversation went in circles for much longer than I am willing to admit and the entire first month was lost because developers had no idea of what to build. It was more important to stay away from that requirements document.
Alright, so we get through the first couple of months and we are now focusing largely on fixing bugs. Why? Because we did not take the time to predict scenarios, which is what you do when developing the requirements documents. Design decisions are made on the spot for every scenario that appears after code complete. What's worse, we place patches all over the place in the form of pop-up messages.
Is there anything good about agile? Well, yes, of course.
- It's good for developers because they no longer have to read two-hundred page documents.
- It's good for developers because they get ‘to work’ right away
- It's good for developers becasue it does help with task decomposition.
- It's good because it brings teams together and everybody knows what everybody else is doing. (There is a flip side to this, though).
- It's good because the concept of the deadline disappears. The focus is on the next sprint. I've been advocating for this for years now.
Conclusions?
In my experience, the methodology is unrealistic. Daily meetings to check the status of things simply do not take 15 minutes (though you get better at this). As soon as someone has an issue the meeting extends. You have the choice to leave, of course, but it is important to find out what's going on. So you stay. When others to whom the issue is irrelevant stay in the meeting, efficiency starts to fall.
Day long or two day long meetings are simply very long meetings to bear. These, I think, try to substitute the development of requirements documents. As you can imagine, many t's and i's aren't crossed or dotted. Hence you end up with increased bug fixing time.
All of this under the so-called Agile methodology.
Having said all of this, I am optimistic and I am certain that each of us will find our place within the methodology and everything will be fine.
Agile is a weapon. If it falls in the wrong hands, we are in trouble.
Agile is egocentric. There is too much focus on the methodology and much less on the work itself.
Agile is very strict, structured and unflexible.
What follows is simply to say that that the nature of the methodology, and why not mention it, the fact that for many of us is a new thing, will force millions of employees across the country to be focused on the methodology and how to properly adopt it. "Make sure you comply with the methodology... or You can't use requirements because we are moving away from waterfall... or I am now in three scrum teams and don't have time for the actual work... or Do you have any obstacles? Yes, too many meetings." These are actual quotes I hear every day in the office. I have never in my live, never, seen a less efficient work structure. Like everything else, how you implement it will guide your [level of] success.
The amount of time that teams spend in meetings is overwhelming. All of this if you are in a scrum team. Now imagine if you were in two.
Let me just clarify for those who may be unfamiliar with the methodology. Agile is a project management methodology (now) extensively used in software development. The methodology establishes teams, known as scrum teams, that work together across projects. Scrum teams work in thirty day periods. Whatever you can get done in thirty days is what gets published. A thirty day period is referred to as a sprint. Agile aims to break from the dependency on requirements documents and pushes away from the Waterfall methodology. This is my second major problem.
I agree that nobody is going to read two-hundred page documents full of software development requirements, much less follow them. Let me share my experience with my first 'requirements-free' application design project.
In December of 2005 we form the first scrum team in the company. We officially form the UI scrum team with myself as UI designer, a set of developers with expertise in the various angles of large application design and, of course, product owners, QA personnel, etc.
The first wrong turn takes place when we decide to dismiss, ignore, or some word of similar characteristics, a document containing feature definitions, use cases, feature flows and pretty much everything the team needed to know about the project. I can't really give many more details here, but the bottom line is that the entire infrastructure for the project was contemplated in the document. Of course, I complain about this because I wrote the feature specification based on extensive user research. Anyhow, the document gets ignored, the developers are ready to start coding and the unthinkable happens.
- What do we build?
- Well, we already discussed the features, replied the project owner.
- I know, but how do you want them built?
- Well, talk to the designer (me), responded the project owner declining any responsibility.
- Yes, I replied. It is all reflected in the feature definition which I distributed several weeks ago.
- I understand, but we are no longer following the waterfall approach, so we do not rely on requirements any more —responded one of the developers.
- I see, so what are you planning on building and how? I prompted.
- Well, you are the designer... the developer replied.
As you can see, the conversation went in circles for much longer than I am willing to admit and the entire first month was lost because developers had no idea of what to build. It was more important to stay away from that requirements document.
Alright, so we get through the first couple of months and we are now focusing largely on fixing bugs. Why? Because we did not take the time to predict scenarios, which is what you do when developing the requirements documents. Design decisions are made on the spot for every scenario that appears after code complete. What's worse, we place patches all over the place in the form of pop-up messages.
Is there anything good about agile? Well, yes, of course.
- It's good for developers because they no longer have to read two-hundred page documents.
- It's good for developers because they get ‘to work’ right away
- It's good for developers becasue it does help with task decomposition.
- It's good because it brings teams together and everybody knows what everybody else is doing. (There is a flip side to this, though).
- It's good because the concept of the deadline disappears. The focus is on the next sprint. I've been advocating for this for years now.
Conclusions?
In my experience, the methodology is unrealistic. Daily meetings to check the status of things simply do not take 15 minutes (though you get better at this). As soon as someone has an issue the meeting extends. You have the choice to leave, of course, but it is important to find out what's going on. So you stay. When others to whom the issue is irrelevant stay in the meeting, efficiency starts to fall.
Day long or two day long meetings are simply very long meetings to bear. These, I think, try to substitute the development of requirements documents. As you can imagine, many t's and i's aren't crossed or dotted. Hence you end up with increased bug fixing time.
All of this under the so-called Agile methodology.
Having said all of this, I am optimistic and I am certain that each of us will find our place within the methodology and everything will be fine.
People I would like to thank and acknowledge for their invaluable contribution to the field of Human Computer Interaction
| Jeff Raskin | For the Mac and for The Humane Interface. |
| Stu Card, Tom Moran and Allen Newel | For their Psychology of Human Computer Interaction. |
| John Anderson | For his work in the field of cognitive modeling and his ACT-R architecture. |
| Jakob Nielsen | For breaking the ice. |
| Pat Jordan | For making pleasure tangible. |
| Jodi Forlizzi | For transmitting a design mindset. |
| Karen Holtzblatt and Hugh Beyer | For putting us in context. |
| Don Norman | For his tea pot. |
| Edward Tufte | For showing us how to display. |
| Alan Cooper and Robert Reimann | For their approach. |
| Barbara Tversky | For her work in the field or orientation and wayfinding. |
| Maneesh Agrawala | For LineDrive and how you got there. |
| Demetrios Karis | For his immersion in the user experience. |
Background
Between 1998 and 2001, I watched parents of a near by day care center take children in and out of car seats. During those years, I observed every possible car model, from small tiny cars to large sport utility vehicles, mini vans and pick-up trucks. I observed parents of all possible backgrounds, physical appearances and abilities, under wind, rain and snow conditions, struggle while sitting their children and strapping them safely into place.
The Problem
Parents and children suffer great strain on their backs when taking children in and out of their car seats. Both parents and child must fit through the car door and into the vehicle. Notice in this sequence of images how the child's back arches almost to a 90° angle (notice the arrows) while the parent's back (mine) is arched at 90° throughout the process.
Proposed solution
Have the car seat rotate to face the parent
Rather than having the parent/guardian get into the car, have the car seat rotate to face the door. A better implementation enables the car seat to ‘come out’ enough to enable the adult to easyly sit the child in the car seat.
Evolution of the Idea: Some sketches
1. Metal bar attached to car's latch system
A metal bar attaches to the car's latch system. The car seat attaches to the bar with a hinge allowing the car seat to detach from one end to face the door.
Benefit: metal bar allows car seat to easily move, or slide, from one side of the car to the other.
Problem: No connection point for upper body area.
2. Hinge directly attached to car's latch system
Problem: No connection point for upper body area; poor rotation of car seat to face door.
3. Platform with rail system
Attached to the latch system, the plaform allows the car seat to turn so it can face the door, while providing the necessary support to overcome the loss of the upper body's connection point.
Problem: No connection point for upper body area.
4. Car seat rotates in position
A platform with ball bearings allowing the car seat to rotate in position.
Problem: No connection point for upper body area; does not actually ‘stick out’ of the car.
Benefit: provides multiple connection points to base, hopefully offsetting lack of upper body connection point.
Introduction
2004. I began analyzing the world of online maps. I conducted an exploratory study aimed at understanding users’ needs and whether those needs were met with the existing mapping tools.
The main finding of the study: very distinct user profiles with very distinct tasks in mind. No one was looking for complex features. Instead, users were begging for little features to support their tasks. Some participants’ comments:
The resulting design: the application had to meet actual user needs while taking into consideration cognitive aspects of orientation and way-finding while meeting the needs of advertisers. With some deviations from the intended design and certain features still to come, the result may be found at:
http://yellowpages.superpages.com/mapbasedsearch/ Description of the study To understand user needs, I conducted the following:
A comparative study in which participants, in a lab setting, compared and discussed various aspects of five different mapping sites. Participants were first interviewed about their use of mapping sites and the purposes for which they used the sites. Participants were then asked to demonstrate how they went about performing their common tasks and were asked to complete those tasks using the five sites chosen for the study.
I researched the psychology literature for background information on orientation and wayfinding, which led me to wonderful work by Barbara Tverski (Dept. of Psychology at Stanford) and to Magresh Agrawala’s LineDrive among others. Fantastic work is also described in “Maps in Minds, Reflections on Cognitive Mapping”, by Roger M. Downs, published in 1977.
A third effort consisted on identifying how people give directions and draw maps to give out to others, for which I interviewed 8 people.
An online questionnaire designed to further understand mapping needs was distributed to roughly 50 respondents.
Lastly, I compiled and analyzed over a thousand messages, regarding maps, received in the customer service department sent by users through the “feedback” feature on the site.
Another person in the group was in charge of managing a long-term nationwide panel in which participants provided detailed narratives of their experiences with online maps.
Next was the realization of how far online mapping sites were from how people function, think, speak, draw and what their goals and tasks are. I was amazed. The problems The problems identified were far too many to list here. A classic trees vs. forest situation. Here are the most notable.
Printing: Lots of problems there, with little user control. Main source of frustration.
Sharing: Sharing with a friend who’s coming to your place or sharing with a boss who’s going on a trip are rather common, yet very distinct activities. Features supporting these tasks are not there even today.
Multiples: The need for multiples appears in various situations. For example, people do not go only to one place at a time. They often times drive to multiple locations in a day. Consider sales people.
Data quality: It actually was (and still is) a big problem throughout the industry, but I won’t get into details here because it is long.
Driving directions: Also various problems here, including the fact that people cannot skip or remove the various steps that take them from home to the highway. They all know how to get to the highway from home, and so they don't want those in their printouts.
Advertising: Simply, too much of it. It gets worse when it is forced on the printout. It also isn't relevant. People do not mind it if it is relevant.
Personalization: Basic personalization features were missing. Things like saving addresses or locating business contacts were brought up.
Usability: A number of problems there as well. From very structured interfaces that only allow you to do one thing at a time, to few error-recovery options, just to name a couple. Meanwhile... Google deploys Google Maps It’s now Feb. of 2005. The world goes wild. Next thing you know, everybody is dragging maps. But the problem is far from solved.
It is not so much that Google aims to organize the world’s information. They organize how we function, how we think and how we approach tasks, including those that involve maps… and I love it.
Google Maps: Awesome? Yes, for some things. But does Google Maps consider how your brain processes geographic information? Does Google Maps help build (and retain) an image of the geography you are navigating? Does Google Maps consider the various types of mapping-related search tasks you might need to do? Can any of the online maps answer yes to any of these questions? No. They are too focused on advertising.
It is hard enough to deliver mapping data, quickly and accurately. It is hard enough to let you drag a map on your browser fast enough so that it is not unbearable. That, I realize. However, I am still amazed at the huge gap between what online mapping sites offer and what users are attempting to do. And it is not even that complex.
Let’s take a step back. Have you ever moved to a new office building? A new neighborhood? A new city? A new country? How long did it take you to learn the new location like the palm of your hand? Most likely, a while. A long while. The importance of landmarks In Maps in Minds, Roger Downs describes three steps in the process of learning a new geographic space. First, we identify landmarks. Landmarks are gas stations, after which we turn right or left, or a glass building, or a red awning, or something that stands out from the rest in a given location. Landmarks are generally used as control points, or turning points. Second, we learn paths between landmarks, even though they are not always the shortest path, but is one that works. Third, we gain configuration knowledge of the environment: not only we know where the various landmarks are in relation to one another but we are able to skip turning points in our navigation.
Landmarks are the most important elements when we navigate geographic spaces. They help us measure and verify progress. This was instantly verified when I asked people to give me directions from downtown Boston to a familiar location, such as home or a favorite restaurant. The design phase The design of the application needed to bring together:
Users’ Goals: these required personalization features, advanced printing capabilities, need to plot multiple locations or multiple destinations in driving directions.
User Profiles: The importance of landmarks and the needs of advertisers: understanding how people navigate unfamiliar geographical spaces and realizing the importance of landmarks lead the way to a patented application bringing landmarks to driving directions.
Flexinle interface: a wide range of users with an even wider range of goals use online maps every day. In-depth understanding of user groups was critical to realizing the need for a flexible interface, capable of hosting hundreds of features without requiring interface adaptations every time an additional feature was added. Conclusions Online maps are still in their infancy and already serve millions every day. The potential to serve customers is almost unlimited and yet, the focus (appears) is to place as many advertisements as possible in the already cluttered real estate. Users notice, and feel, this. I mean “feel” because ads are everywhere and are not relevant. Before arriving at the site, the user knows what is being sought and what the expected outcome of the search is. My research, and that of many others, indicates that advertising are in fact welcome by users if they were, simply, relevant.
User needs very almost from person to person. There is no one-size-fits-all. Users are craving for features that serve their needs. Many features. Not complex features, just varied features based on each individual’s profile.
Don’t plot advertisers hoping that users will click on them a million times. Understand what the user is trying to do. Display advertisers that support a task, not a keyword. Know your users.
The main finding of the study: very distinct user profiles with very distinct tasks in mind. No one was looking for complex features. Instead, users were begging for little features to support their tasks. Some participants’ comments:
“Looking for a interactive map for electrical contractors in the NYC area as well as Brooklyn, and Staten Island. Is there a way to do this?”
“It would be nice to be able to print the whole map, with icons from multiple searches”
The resulting design: the application had to meet actual user needs while taking into consideration cognitive aspects of orientation and way-finding while meeting the needs of advertisers. With some deviations from the intended design and certain features still to come, the result may be found at:
http://yellowpages.superpages.com/mapbasedsearch/ Description of the study To understand user needs, I conducted the following:
A comparative study in which participants, in a lab setting, compared and discussed various aspects of five different mapping sites. Participants were first interviewed about their use of mapping sites and the purposes for which they used the sites. Participants were then asked to demonstrate how they went about performing their common tasks and were asked to complete those tasks using the five sites chosen for the study.
I researched the psychology literature for background information on orientation and wayfinding, which led me to wonderful work by Barbara Tverski (Dept. of Psychology at Stanford) and to Magresh Agrawala’s LineDrive among others. Fantastic work is also described in “Maps in Minds, Reflections on Cognitive Mapping”, by Roger M. Downs, published in 1977.
LineDrive
A third effort consisted on identifying how people give directions and draw maps to give out to others, for which I interviewed 8 people.
An online questionnaire designed to further understand mapping needs was distributed to roughly 50 respondents.
Lastly, I compiled and analyzed over a thousand messages, regarding maps, received in the customer service department sent by users through the “feedback” feature on the site.
Another person in the group was in charge of managing a long-term nationwide panel in which participants provided detailed narratives of their experiences with online maps.
Next was the realization of how far online mapping sites were from how people function, think, speak, draw and what their goals and tasks are. I was amazed. The problems The problems identified were far too many to list here. A classic trees vs. forest situation. Here are the most notable.
Printing: Lots of problems there, with little user control. Main source of frustration.
Sharing: Sharing with a friend who’s coming to your place or sharing with a boss who’s going on a trip are rather common, yet very distinct activities. Features supporting these tasks are not there even today.
Multiples: The need for multiples appears in various situations. For example, people do not go only to one place at a time. They often times drive to multiple locations in a day. Consider sales people.
Data quality: It actually was (and still is) a big problem throughout the industry, but I won’t get into details here because it is long.
Driving directions: Also various problems here, including the fact that people cannot skip or remove the various steps that take them from home to the highway. They all know how to get to the highway from home, and so they don't want those in their printouts.
Advertising: Simply, too much of it. It gets worse when it is forced on the printout. It also isn't relevant. People do not mind it if it is relevant.
Personalization: Basic personalization features were missing. Things like saving addresses or locating business contacts were brought up.
Usability: A number of problems there as well. From very structured interfaces that only allow you to do one thing at a time, to few error-recovery options, just to name a couple. Meanwhile... Google deploys Google Maps It’s now Feb. of 2005. The world goes wild. Next thing you know, everybody is dragging maps. But the problem is far from solved.
It is not so much that Google aims to organize the world’s information. They organize how we function, how we think and how we approach tasks, including those that involve maps… and I love it.
Google Maps: Awesome? Yes, for some things. But does Google Maps consider how your brain processes geographic information? Does Google Maps help build (and retain) an image of the geography you are navigating? Does Google Maps consider the various types of mapping-related search tasks you might need to do? Can any of the online maps answer yes to any of these questions? No. They are too focused on advertising.
It is hard enough to deliver mapping data, quickly and accurately. It is hard enough to let you drag a map on your browser fast enough so that it is not unbearable. That, I realize. However, I am still amazed at the huge gap between what online mapping sites offer and what users are attempting to do. And it is not even that complex.
Let’s take a step back. Have you ever moved to a new office building? A new neighborhood? A new city? A new country? How long did it take you to learn the new location like the palm of your hand? Most likely, a while. A long while. The importance of landmarks In Maps in Minds, Roger Downs describes three steps in the process of learning a new geographic space. First, we identify landmarks. Landmarks are gas stations, after which we turn right or left, or a glass building, or a red awning, or something that stands out from the rest in a given location. Landmarks are generally used as control points, or turning points. Second, we learn paths between landmarks, even though they are not always the shortest path, but is one that works. Third, we gain configuration knowledge of the environment: not only we know where the various landmarks are in relation to one another but we are able to skip turning points in our navigation.
Landmarks are the most important elements when we navigate geographic spaces. They help us measure and verify progress. This was instantly verified when I asked people to give me directions from downtown Boston to a familiar location, such as home or a favorite restaurant. The design phase The design of the application needed to bring together:
Users’ Goals: these required personalization features, advanced printing capabilities, need to plot multiple locations or multiple destinations in driving directions.
User Profiles: The importance of landmarks and the needs of advertisers: understanding how people navigate unfamiliar geographical spaces and realizing the importance of landmarks lead the way to a patented application bringing landmarks to driving directions.
Flexinle interface: a wide range of users with an even wider range of goals use online maps every day. In-depth understanding of user groups was critical to realizing the need for a flexible interface, capable of hosting hundreds of features without requiring interface adaptations every time an additional feature was added. Conclusions Online maps are still in their infancy and already serve millions every day. The potential to serve customers is almost unlimited and yet, the focus (appears) is to place as many advertisements as possible in the already cluttered real estate. Users notice, and feel, this. I mean “feel” because ads are everywhere and are not relevant. Before arriving at the site, the user knows what is being sought and what the expected outcome of the search is. My research, and that of many others, indicates that advertising are in fact welcome by users if they were, simply, relevant.
User needs very almost from person to person. There is no one-size-fits-all. Users are craving for features that serve their needs. Many features. Not complex features, just varied features based on each individual’s profile.
Don’t plot advertisers hoping that users will click on them a million times. Understand what the user is trying to do. Display advertisers that support a task, not a keyword. Know your users.