Pedro Cubillo user research . interaction design » web . mobile . tv
home work words images contact




Design Philosophy

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.
On Cognition

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 most significant 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:
  • What triggers a search in the first place?
  • Why are we constantly searching?
  • Information needs: time based (sporadic vs. permanent) and type based (descriptive, conceptual, functional, procedural, explanatory)
  • How do we formulate a search task based upon the tools made available to us? In a bookstore? A library? The web? Searching on TV with a remote control?

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.
On Agile

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.
People

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.