Modules and Wholes

User research takes time and costs money. Small wonder designers are always seeking ways to cut corners, and by-pass research altogether.

The range of theory-heavy, fact-lite techniques that claim to be user-focused multiples all the time. We have scenario-based design, usage-based design, activity-based design; all are abstractions, looking at what users might or ought to be doing, more than what they actually do and want. Some might find this characterization unfair. Activity centered design is supposed to look at the users' context, and what the user does. But AT does so by looking at the user in a passive role, not as an agent controlling technology. Scenario-centered design and usage centered design similarly look at users as cogs in a system, fulfilling their role of conforming to the expectations of the system. The goal is to make sure users don't slow the system down, not to make the system respond to the pace of the user.

What these approaches do offer is an alternative to totally user-driven design. Users are vitally important, but users are not always the only -- or even the most broadminded -- definer of needs for an information ecosystem. We need research to provide credibility to the interests of users. But designers need to advocate user interests in the context of other stakeholders. Stakeholder trade-offs are political decisions involving people, not abstract equations comparing marginal efficiencies of inanimate pieces.

From time to time I have seen passing references to the existence of two tribes in usability: those who make interfaces, and those who critique them. It is a strange cohabitation of roles: ultimately striving toward the same ideal, but involving different skill sets, different temperaments, and an uneasy combination of synergy and contradiction.

One's understanding of usability is often colored by which tribe one is most involved with. In the largest companies, their may be dedicated usability testers, who are separate from UI designers and IAs. Usability consultancies often dominated by non-designers (testers and other user researchers), while agencies tend to hire designers and IAs. Many of us get involved in all aspects, researching, designing, testing, though we find ourselves doing some things more often than others.

In my experience, it is rare for someone to be equally talented at user research and UI design. Still, there are good reasons to have experience with both roles, though it can be problematic to do both roles on the same project. The tester who also has experience with design can overcome some of the limitations of the testing mentality. Testers tend to focus on what's wrong and not working, and offer didactic advice frequently containing the word "should." UI designers can get caught up in the rigidities of style guides and uniformity, which can get abstracted from the realities of what users want and need. A tester who has experience with UI design is more able to offer useful suggestions to designers on how to fix a usability problem that has emerged during testing. A UI designer with testing experience might be more sensitive to contextual peculiarities.

While the two cultures use complementary approaches, their basic temperaments are different enough to limit a fluid change in perspective. UI designers are focused on constructing an interface, while testers are focused on de-constructing it. Testers are more focused on what is not possible, rather than what is possible. They often are reluctant to offer any "solution" at all to a problem, out of fear their solution will test poorly. Some usability engineers shun offering any design advice at all.

UI designers can get invested in their solution, and can lack emotional and mental detachment to let go of it. It is no fun seeing a technical UI solution that has been developed over weeks get dinged by users. Unlike their more artistic web designer brethren, UI designers are presumed to be experts utilizing empirically developed principles and good practice. Clients are very happy to believe that a solid body of best practice exists that can be drawn upon to design a flawless UI from the start. Experts can be reluctant to take risks, and play with options, when prior experiences suggest a possibility of user hesitation, or implementation problems.

If one attempts to do design and testing on the same project, the potential for inner conflict escalates. Extraordinary self-discipline is needed to remain open to user suggestions in the UI design phase, despite one's fears that the design is getting too complex and won't test well. In testing, one needs to push one's elegant solution to the breaking point to assure that it isn't just you who is in love with the concept. Testing one's own UIs means turning off any hint of enthusiasm, to avoid getting a "want to please" reaction from users.

Playing both roles involves maintaining enthusiasm for nascent ideas, while ditching ones that don't work without a loss of pride when the client seems confused why you were so keen on one approach only to drop it cold. To bridge these paradoxical demands, one needs to be able and willing to criticize one's own ideas, to undermine one's own self-confidence that you have figured it out.

Personas can potentially address many aspects of users. Each of these facets may be important to how users relate to an interactive design. But often, these facets just don't cluster around common themes, despite our desire to group everyone into a few easily digested categories. The essential problem with the persona concept is that attributes of users don't predictably co-vary with each other.

There is no common definition of what comprises a persona. Here is my own, non-exhaustive list of persona attributes that occurred to me today. You may dismiss some, or more likely, have more of your own to add. Users can be different in many ways:

Experience

• with technology (existing or analogous, from virgin to novice learner to uncomfortable straggler to power user)
• with a subject domain (what they know about investing, or airfare prices, or whatever);
• life experiences (stage of life, encounters with significant events or circumstances)

Personality

• socialability (e.g., willingness to ask for help, independence);
• anxiety (toward technology, concept of self efficacy);
• cognitive style (e.g., detailed oriented or not);

Motivation

• career ambition;
• social competitiveness;
• expectations (e.g., about ease of technology, complexity of a subject);
• playfulness;
• curiosity
• helpfulness (willingness to collaborate or share information)

Roles

• job roles (e.g., functional speciality, multifunctional responsibilities);
• social roles (may be context dependent);
• family roles;
• authority/discretion in various situations;

Goals

• first-order goals (amount of time willing to spend, immediate demands of the situation);
• second-order goals (instrumental accomplishments, KPIs, psychic/hedonic rewards, financial payoffs)

Even this short list highlights how many variables can exist within a user. These variables may be interrelated. Experience can affect motivation, and vice versa. Motivation can affect goals, and so on. But just because factors can be interrelated doesn't mean they occur together in predictable ways. Sometimes they do: teenagers are likely to have little experience with investing and also have a low motivation to worry about retirement. But my experience has been that opportunities for such stereotyping is limited, and is often not even interesting.

People are complex, and becoming more complex all the time. Imagine a persona for an employee in an organization. Perhaps twenty years ago one could safely make stereotypes about certain employees. Worker responsibilities were clearly defined, workers were recruited from homogeneous pool of applicants, and people's experience was safely defined by the number of years they had at a company. Today, workers may be doing any number of tasks (roles?), have had few or many jobs previously (which could affect motivation or experience any number of ways), be on short term contract (motivation?), be of an indeterminate age (experience?), and not really be molded by the company culture they operate in (personality?). A similar blurring of identity is evident in personal lives as well.

There are simply too many variables to consider in personas to allow them to cluster around five or six personas in a tidy fashion. (Most people consider five or six the maximum number of personas that can be comprehended easily -- unless you are into Dostoyevsky.) Another problem: two personas may be nearly identical, except for a key difference on one variable. By discussing the persona as a "whole person" (even if fictional), it becomes difficult to see the one difference between two people when the discussion is about the person instead of the attribute. The temptation exists to try to make the two people different in other ways, to exaggerate their difference.

I can see uses for personas, and I have been told by others they have had success using them. But I urge restraint. The technique can gained popularity without much critical examination.

Personas and scenarios are meant to make an abstract, intangible interaction process more concrete. But more often than not, they fail miserably: offering a simplictic, waffly caricature of something that is complex and nuanced. I am beginning to think that both tools are more dangerous than useful, and give user centered design a bad name by pretending to be user centered when in reality these techniques rely on assumptions, distortions and conjectures.

I have written previously about how confused the concept of personas is. I know that personas can be useful when one is clueless about your market. You may be a designer who is making something totally new, and need to get a feeling for who might use it. Or you are a high level executive who can't deal with details in a short briefing, and needs a mental picture of who the customer is. But designers are a bit arrogant to assume that clients are generally clueless about their customers and users. Generally the client knows far more than the designer. Developing the persona is less for the benefit of the client than it is for the designer.

Another problem of personas is that they very rarely are based on rigorous research. The detail they contain may sound impressive, but it is often invented. To be credible, every aspect of a persona should reflect real details of the lives of multiple people. If your persona reads Cosmo, it is because you have met more than one real user who actually reads Cosmo. Anything less is just fiction, not user research.

But if someone has done real user research, meeting with numerous people who share certain characteristics, a persona is a poor representation of that research. Personas suck the nuanced details out of research, and present a bland stereotype, who might as well be a cartoon character. As a cast of "characters", personas are simply stage actors. Few persona developers can answer what proportion of all users a given persona represents. Simply saying "there are some people like Grandma Jane" is fairly meaningless. Design research can highlight many things that clients aren't aware of. Unfortunately, personas are too crude to deliver these details.

A close relation to personas, scenarios, also proves imprecise. It is true that people relate to stories. But is it also true that stories are gross simplifications of reality. Again, we find literary invention masquerading as research. Very often, scenarios are a substitute for user research. It is far faster (and cheaper) to brainstorm some stories about what users might want to do, than to actually do the research to find out. As a starting point, scenarios are fine, as long as one recognizes that it is just speculation. What tends to happen is that the brainstorming is codified into requirements. Proponents of scenarios like John Carroll have caused the abstract concept of "use" to become confused with the concrete concept of "used".

Scenarios suffer from several problems. As stories, they only address the big themes, and not the minor details. The devil is in the details, and scenarios don't help there. Scenarios can indeed led to a false sense of accomplishment: the user wants to X, we offer X, so we are on target.

Another problem with scenarios is that they are based on speculations. "Suppose the user...", "the user may want to...", etc. As with other pseudo-user centered techniques such as "expert reviews", scenarios create two distortions: false issues, and missed issues. Scenarios can cause designers to worry about issues that in reality aren't a concern to users. Being based on the imagination of designers, instead of the reality of users, scenarios also miss important issues users may be concerned about.

Design researchers need to be honest about the purposes and limitations of personas and scenarios. Everyone may have a novel inside them waiting to be written, but don't use personas and scenarios as a pretext to write it.

I am working on a project at the moment that involves computerizing some processes that are currently done on paper forms. Surely everyone knows that paper forms are passe, and that great economies are gained by capturing this information electronically. Indeed there are benefits to the computerization -- the information can be accessed more easily by a wider group of people, and the data can be reused in other situations. But what is interesting is how robust paper forms can be. Rather than being a static receptacle for information, the forms I am dealing with are actually dynamic frameworks for collecting classes of information, instead of fixed data fields. If a customer has requirements that don't fit the architecture of the form exactly, the form can be amended through crossing things out, adding things on, and making margin comments. Humans can understand these complexities, but computer programs gag on them. Trying to figure out a computer form that can handle all the potential variations of customer information is proving quite a challenge.

I have always used public transport. Until I moved to New Zealand, I never even owned a car. Even with a car, I ride the bus daily. Wellington is a small city (a town really), but there is little parking, and I hate driving.

I like the idea of traveling by bus (in the absence of an underground train), but I don't like the Wellington bus system, which suffers from a couple of design flaws. A couple of events this week have highlighted that money won't fix a flawed design.

Problem one: incomprehensible fare system. Wellington uses a strange system of charging fares based on "sections." Other cities around the world charge a flat rate for a ride, or use a zoning system where it is obvious if you are in the inner zone or an other geographic zone, based on commonly understood geographic boundaries. Wellington's sections are mysterious invisible lines that cut across bus routes, slicing them into segments. You pay according to how many sections you cross, if you can figure that out. Each route would seem to have a different arrangement of sections, as far as I can determine. It is with great difficulty that one can find a map showing how sections are divided on a bus route. The Byzantine system requires a dedicated employee to get on buses to inspect tickets to make sure passengers haven't entered a section they haven't paid for. I was encouraged this week to see an expensive new signing system for bus schedules introduced. But still no information on where the sections change, and how much it costs to go from one destination to another.

Problem two: trolley buses. Wellington is one of few towns that decided to replace railed-based trams with tram-like buses, locally called trolley buses. They look like buses, they jerk around like buses (unlike the smooth ride trams), but they don't have the freedom of movement of buses. They are tethered to unsightly electric cables overhead, which means that each trolley bus must follow the one in front of it. If one trolley bus is delayed, or broken, all trolley buses behind it must wait. There is one set of cables, so none can pass. It has the disadvantages of a subway train system, except that it adds to traffic congestion at the same time. Yesterday, a rain shower knocked out the electricity for the trolley buses, though the rest of the town was unaffected. Dozens of trolley buses were clogging the streets, stranded like beached whales. Older trolley buses have a regular tendency to become disconnected from the overhead power cables while in operation, which stops the bus and requires the driver to get out and reconnect the cables, dodging oncoming traffic. Wellington is buying new trolley buses, which will hopefully stay better connected to the cables, but the essential problem of the trolley queue remains.

All this talk in recent years of "design strategy" has left me cold. Companies adopt a strategy to achieve an outcome. A plan is a list of buttons to push to make something happen favorable to the company. What are the components of design strategy?

• branding (how do we look?)
  
• experience design, especially as it relates to retail (make buying fun!)
  
• buzz and viral marketing (get people to talk about your product)
  
• innovation, specifically shortening the product lifecycle (planned obsolescence)
• being theatrical (keep moving and people won't focus)
  

What is pernicious about design strategy is that it attempts to confuse what the company wants from consumers, with what consumers want for themselves. I believe companies have legitimate self-interests, and indeed can have a tough existence meeting competitive pressures. But they need to address their needs in an honest way, and sometimes they don't always come clean about the boundaries of who they are and what the customer wants.

To put it crudely, design strategy is about colonizing the mind of consumers. The essential concept is to make consumers feel they are asserting their individuality by buying a product. The strategy is to conflate the thoughts of a company's marketing department with the thoughts of an individual. At its worst, it gives credence to the notion of "No Logo" (a book, by the way, I haven't read, because I imagine it as too unfair on companies, and too naive on the realities of making a living.)

Before our current infatuation with design strategy, people used to talk about "design management." Design management was a humble concept, almost boring in its intention. Basically, design management was about developing consistency in communication. Corporate identity and product design were meant to be consistent across product lines - a uniform look. Design management had its origins in the German electrics conglomerate AEG. It reached its apogee in Ulm-school followers, such mittelstadt (middle sized, family owned) firms as Braun and Gardena. Outside Germany, deign management was enthusiastically embraced by Philips, and the most Germanic US corporation, IBM. It was boring, perhaps (in retrospect), but it was honest, and people understood who they were buying from and what that company was promising. It was corporate -- indeed not flashy -- but what it sacrificed in consumer choice was offset by being direct and forthright.

Between the poles of design strategy (phony choice) and design management (corporate-level choice) is a third alternative. It doesn't have an official name, but call it craft-creative entrepreneurship. While it can be found in many places, it is most readily found in Italy. There are several distinguishing features. First, the entrepreneurial company is family-owned. There is a blood history to what the company does, it doesn't change knee-jerk with fashions. Second, the company's products are based on craft. They aren't produced in millions. The designer and maker are very near each other, not tens of thousands of kilometers away. The fusion of design and production in craft means the product has a soul. It expresses the creativity of the designer, but is not a vanity piece. Like all craft, it references a common historical language, and plays with the boundaries of what has been done previously. People can enjoy these products as the creative output of their creator, without feeling their personal identity needs to be involved. They can admire the creativity of a product, but respect that creativity for what it is. Unlike design strategy-derived products, people are celebrating the designer and maker, not making a statement about themselves, their tastes or their lifestyle. This is because the hallmarks of the designer/maker are readily evident, instead of being anonymous, being diluted by a mass production line somewhere in China.

There is growing discussion about authenticity in life and commerce. Design needs to join that discussion.