 |
« | Week of Feb 15 | < | Individual Entries | > | Week of Feb 29 | » |  |
 |
 |
The Quality of Consumption
psychology
February 28, 2004, 07:52 PM
I read an article found via Neema which references psychological studies that found that on average people appreciate experiential consumption more than material consumption. By experiential consumption, we mean those purchases that are made with the intent of acquiring some sort of life experience, such as traveling to a foreign country, going to a concert, or going out to a bar with friends and having good conversations. By material consumption, we mean those purchases that are made with the intent of acquiring some new artifact, like cars or cameras or clothes.
The article makes a few dubious claims in its analysis, but this fact alone is interesting; like Neema, I found it validated my own goals and values. I've sought to enhance my life's experiences over the amount of stuff I own; one of my goals for the future is to increase the quality, quantity, and diversity of these experiences.
It's interesting to reflect on the implications of this research for designers. If we hope to craft products that improve people's lives, are we kidding ourselves by believing that any new "thing" can really bring our customers any meaningful happiness? Food for thought, for sure.
It'd be great to see more research investigating what makes people happy. We might turn up other interesting surprises.
Eric Raymond: Open-Source Usability Advocate?!
software development, usability
February 27, 2004, 10:01 PM
I was idly surfing the blogspace (doesn't that sound so much nicer than "blogosphere"?) this afternoon when I happened across Julian Missig's blog (a fellow CMU student and a co-worker of Dana's, of all things). He points to an article hot off the press by Eric Raymond where the famous OSS guru actually argues in favor of fixing the open source software usability problem! I could barely believe it until I read the article; frequent readers will recall that I've been studying the OSS usability problem for several months now. But though I've found some encouraging evidence of OSS developers who are starting to get it, I never, ever thought I'd read an article like this from ESR. Some of his suggestions were right on, others I'm not so sure about, but the core ideas about the ways open source software needs to change are right on the money.
I've sliced out some particularly interesting bits below, with commentary.
Aunt Tillie, at this point, is either resigning herself to another session of being tortured by the poor UI choices of well-meaning idiots or deciding to chuck this whole Linux thing and go back to the old Windows box. It blue-screened a lot, but at least it allowed her the luxury of ignorance — she didn't have to know, or care, about what a JetDirect or a CUPS might be.
OSS advocates often emphasize superior stability or security of OSS tools over commercial alternatives. Whether these things are true or not, they are irrelevant to average home users; if Raymond's fictional everyuser, Aunt Tillie, can't figure out how to set up and use her PC, it's worthless to her. Putting up with the occasional crash or theoretical security glitch is worth it to her if it means she doesn't have to be a tech wizard or Unix hacker to get her machine to print photos and send email.
I am not ignorant, but I have my own equivalent of Aunt Tillie's problem. I know I want one of the top two methods, but I don't know which one. And I don't want to know or care about the difference either; I have better things to do with my brain than clutter it with sysadminning details.
Another good point; even though OSS gets most of its support within technical circles, it's not just nontechnical users that software with poor usability alienates. Raymond is far from representative of the technical skills of the average computer user, and even he barely succeeds at performing this seemingly simple operation with CUPS. I, too, am far more technical than your average Joe, but I've played out scenarios similar to Raymond's with my own linux server many, many times. Sometimes, after much wasted time, I succeed at my task. Other times I fail, and figure out an ugly workaround or just give up and go back to the rest of my life. Like ESR, I have better things to do with my brain.
The thing to notice here is how far behind we have left Aunt Tillie. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong . The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.
Huzzah! Good documentation does not replace good interface design. And if the interface is poor, it's documentation is necessarily confusing, since a convoluted interface requires complicated instructions on its use. Too often in OSS, the solution to poor design is lengthy documentation. Proprietary software companies learned long ago that user's don't read documentation. It's time OSS learned the same lesson.
GUI tools and voluminous manuals are not enough. You have to think about what the actual user experiences when he or she sits down to do actual stuff, and you have to think about it from the user's point of view.
I could hardly have put it better myself, if someone asked me to capture in a nutshell the problem with OSS efforts to bring usability to their software. Open source projects are copying the trappings of well-designed software interfaces without understanding the substance. The result is lots of GUIs and manuals, but interaction designs that all too obviously had little to no thought put into them. This must change, if OSS is to compete with proprietary software in anything other than the (shrinking) niche of highly technical audiences.
I'll note that I had such a hard time believing my eyes while reading this article that I checked the domain name repeatedly to make sure it was really published by Eric Raymond.
None of this is rocket science. The problem isn't that the right things are technically difficult to do; CUPS is already supposed to have discovery of active shareable queues as a feature. The problem is that the CUPS designers' attitude was wrong. They never stepped outside their assumptions. They never exerted the mental effort to forget what they know and sit down at the system like a dumb user who's never seen it before — and they never watched a dumb user in action!
Again, this is right on (although I might take exception with referring to users as "dumb", if I wasn't in such a good mood). I've advocated bringing usability professionals and interaction designers into the open source community precisely to solve this problem; it's hard for anyone to step outside their assumptions and see a system they created as it is seen by those who are unfamiliar with it. It's especially hard for software developers who, while extremely skilled at producing quality code, are unskilled at understanding human limitations and seeing the system from the user's perspective. Hence the need for more heterogeneous skill sets within the OSS community.
CUPS is not alone. This kind of fecklessness is endemic in open-source land. And it's what's keeping Microsoft in business — because by Goddess, they may write crappy insecure overpriced shoddy software, but on this one issue their half-assed semi-competent best is an order of magnitude better than we usually manage.
When I read this section, I wasn't quite sure whether to dance for joy or go into shock.
It's clear that, beyond all hope, Raymond recognizes that there is a problem. With his influence, perhaps others will recognize it as well. And that, of course, is the first step towards a solution.
Because I believe it is a solvable problem. Although many OSS developers are currently naive about usability and interaction design methods, this can change. Although most interaction designers and usability professionals do not currently get involved with OSS projects, this too can change, if a place is made for them. And what's more, I highly suspect that a fully integrated, properly honed open source software community, with interaction designers, usability professionals, software developers, and end-users all working together, could produce software far superior in both design and technical quality than any proprietary company has yet been able to manage.
But that future does not yet exist, and it will take a lot of work to get there.
As I said before, the point of this essay is not especially to bash on the CUPS guys. They're no worse than thousands of projects out there, and that is the point. We talk about world domination, but we'll neither have it nor deserve it until we learn to do better than this. A lot better.
Amen, brother.
Posted by Julian on February 29, 2004 at 02:33 AM
I saw your post in my TrackBack. I've definitely seen you around campus on multiple occasions, though I don't remember exactly in what context.
Glad you found something from my blog useful--it's always fun to run into other CMU people.
Posted by eefzeuzk on October 18, 2007 at 12:41 AM
yotnrmtd lbymersp http://lczndkza.com lwaxrnar esgjidcs [URL=http://arphrkaz.com]fopvygaq[/URL]
Email Rob:
Information Design In Practice: Agnew Moyer Smith
design, information
February 25, 2004, 11:57 PM
Karen, our Mapping and Diagramming teacher, took us on a field trip yesterday to Agnew Moyer Smith, an information design consultancy in Pittsburgh's Southside. Don Moyer, Karen's husband and a partner in the firm, gave us a tour of the facilities and talked to us about a few of his current projects as examples of how he practices information design. Agnew Moyer Smith specializes in making complex technical topics clear and accessible to non-experts, something I'm particularly interested in.
Don spent the most time on a project he'd been working on to develop an information design piece that clearly explains how RFID tags can be used to improve supply chain management. He started out by reviewing an existing piece on supply chain management that AMS had produced for a previous client. This enabled him to set the stage for his own research by working from a similar document whose quality he trusted. He also began to look for sources of information on the domain, investigating a technical paper on RFID, some articles about it in the popular press, and his client's own initial attempts at explaining the process. Don warned against gettting caught up in too much research; he could have probably found hundreds of articles on the subject and although he may have learned a little bit of important information from every one of them, he would have spent days and days going through them all. It's best, he said, to find the book on the topic written for 8-year-olds; that way someone else has already done all the hard work of pulling all the information together and making it understandable. If such a book doesn't exist, however, then you'll have to make do with the most clear and comprehensive sources you can find.
Next, he started collecting together a list of all the nouns (things, actors, etc.) that existed in his problem domain. Then he started listing all the verbs that each of these actors could perform. Interestingly enough, this is the same approach software engineers take when modeling a problem domain for developing an object-oriented software design.
Don prepared a brief of the project for his client to ensure that they were both on the same page as far as the project's requirements went (in theory a brief like this is prepared by the client, but Don says that has never happened in all the years he's been working. The brief, if one exists, is prepared by the designer, just as requirements are developed by software engineers and not handed to them by clients). This brief contained:
- A short objective for the project.
- A description of the intended audience of the communication piece.
- The information that the client wants to know before completing the communication piece.
- The information the client already knows (or thinks he knows) about the subject.
- A list of the main messages or "story elements" that the final communication piece must clearly portray.
After getting the client's approval on the brief, Don started developing sketches of the process as well as a notation language for the nouns and verbs he had identified earlier. He then started assembling the spread itself. Don prefers to develop information spreads before powerpoint presentations or other types of information design; he finds that the page works well to force constraints on the design project that ensure clarity and effectiveness of results that might be lacking in a more permissive medium like a presentation or video. This is very much in line with my own rants on the value of constraints.
Once Don reached a solution he was happy with, he moved the project along. Although he would have liked to explore more solution possibilities, he recognizes that making a decision in the development phase early enough to leave room for sufficient refinement is important.
Next, Don wrote the prose for the piece in the form of numbered steps; he believes that it's important for designers to be able to write their own clear, concise copy. He then merged the text with his sketches, and called in a colleague to conduct a critique of his work. His colleage came into the crit cold and played at being a user, pointing out areas where he didn't understand what was being communicated. Don remarked that its common practice in AMS to post designs up in the kitchen or on boards around the space to get comments from the other employees as they wander around the floor.
Finally Don handed off his project to an illustrator to come up with some final iterations. Don described the finished project as "not just a picture, but a story". Thus the need for spending eight weeks on it.
Afterwards, Don showed us around the very impressive AMS space, which completely blows anything at CMU out of the water. The space was very much tailored to the work; projectors were configured to be easily connected to any laptop, bookshelves with design-related books abounded, small workspaces could be reserved by teams so they'd have a permanent location to store work relating to their project. Interestingly, there were no personal private spaces at AMS; everyone had an open desk. Even more interestingly, Don himself had the same setup; his desk didn't really look much different from that of any other employee. No clearly visible hierarchy in this organization. There were also many common areas to encourage conversation and collaboration, although the atmosphere also created enough quiet in the working areas for employees to get things accomplished without interruption. There were closed off conference rooms as well as small booths for private meetings and telephone calls.
Finally, Karen showed us some small booklets that Don produced apparently just for fun about a variety of topics that he wanted to know more about. Don's motives were mixed, however, since he also sent copies of these booklets around to important contacts in the hope that they would bring more work. In many respects, this reminded me of the motivations of open source software contributors.
It was a great experience to see a practicing designer at work. I wish we got more field trips in this graduate school thing.
Dan went along as well; his commentary is also available.
Email Rob:
Users as Co-designers
design
February 24, 2004, 01:52 AM
Dan reports on a talk given by Liz Sanders on design research and, specifically, generative research, which sounds a lot like participatory design to me. This take on design research views the designer more as a facilitator who works to bring out the creativity and expressiveness of a product's or system's users (or potential users) to generate new ideas for its design. I have discussed this idea in the context of open source software development some in the past.
Needless to say this redefinition of the role of the designer is controversial. Dan gives his personal opinion (a rare thing, for his posts); he is strongly opposed to the idea of involving users in this manner. And radically participatory design is a hard idea to come to terms with; the designer must relinquish a lot of control over the design itself and the design process to embrace it. But let's think a little about where the true problems lie.
First off, the question is not "should users be involved in the design process?". Anyone who professes to practice human-centered design believes they should be; the question is in what capacity. On the low-end, designers keep tight control over the product; they may bring in users for a few interviews during the exploratory research phase or to run user tests during the refinement stage, but never care to ask a user if he has any design ideas. On the high-end, designers pass the buck and ask the users to do the entire design for them; this is the approach Extreme Programming essentially takes. And there's a whole range of ideas that fall in between these two extremes. But what is the right approach to take?
The problem with the high extreme is clear: users are not trained as designers and thus don't have the background in human abilities and limitations, design skills and theories, and plain old experience with what works and what doesn't that is so essential to creating great designs. Moreover, any individual user is caught up in her own way of working; she might be able to design decent solutions for herself, but there may be many other types of users of the product or system in question and she's unlikely to be able to put herself in their shoes (or even know who they are). All these things are truisms in the usability and interaction design fields.
But there's a problem with the low-end as well, and that is that designers don't have a monopoly on good ideas. There are many software designs on the market that were likely created by designers, but which could definitely stand to gain from listening to user feedback (some of Apple's work comes to mind...). I suspect it is not at all uncommon that a user will be working with an application, get frustrated, and come up with a really great idea of how the application could have been designed differently to better support his task. Too bad the designers will never hear of it.
Part of this is due to the universal creativity Liz alludes to, but much of it also comes from the simple fact that users know their work far, far, far better than any designer ever will, no matter how much research he does. This puts the user in a position to have design insights that no non-user could never have. Remember that the essential interaction is between the user and the product or system being designed. The designer is a third party; he may scrutinize this interaction to death, but that's still very different from being a part of it.
In The Cathedral and the Bazaar, Eric Raymond gives programmers advice such as "Treat your users as co-developers" and "The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." Many minds can come up with more and better ideas than one mind can; open source developers have known this for a long time and social science research supports it. This is one of those areas where human-centered design could stand to learn from open source.
I believe that part of the resistance to participatory design among designers springs from the old notion of "genius"; that there's some magic inspiration that the Great have and the common do not that causes the Great to produce amazing works of art, design, math, programming, etc., etc. You're either born with it or must go through lengthy rituals to obtain it, but if you don't got it, you're screwed.
I don't believe in genius, really. Yes, it is best to have one mind that is ultimately responsible for the final product; nobody likes designs produced by a committee. But one mind is flawed and limited when it works alone. It must be willing to reach out to others in whatever ways are appropriate to overcome these limitations.
But designers need not fret about losing their place in society (a good thing, since I count myself among their number...). There will always be a need for those experts who've been trained in the lore of the profession and who've learned from the trials of producing designs. They must be facilitators, integrators, inquirers, and many other things besides, including creators and idea generators. They are valuable now and their value will only increase as their profession matures and expands. But to do this, they must not shut out avenues of potential growth.
I realize I still haven't answered my own question: what is the right amount of user involvement in the design process? The pat answer is "it depends on the design problem" (bet you've heard that one before). But it's more complex of course; the designer must weigh the value of user input, the difficulty of integrating user ideas and identifying good ones, the availability and willingness of creative users, and so on. But most importantly, the designer must realize when he needs to step back and not be the sole designer; when a user's idea may be more valuable than his own. Genius or not, the truly great creator is marked by his willingness to cede control over his creation in service to bringing it closer to perfection.
Posted by Dan on February 24, 2004 at 07:48 AM
I wouldn't say I am strongly opposed to the idea of involving users in participatory design, but I am strongly opposed to the idea of a designer being relegated to that of a facilitator. God knows I have stolen good ideas from users about designs: in a sense, this is partially what user research and product testing is all about.
It does go back to the old "genius" (slightly derogatory term) or "great man" (derogatory) idea. I'm not much of a romantic, but I do believe that individual people can and do make a difference, for good and ill, in how we live our lives. Certainly not all designers are geniuses, but then again, some probably are. Paul Rand and Raymond Loewy spring to mind. The leaps from the problems to the design solution are sometimes far.
As far as users being the content experts: no argument from me, except to say there is a benefit in someone without any vested interest but with a broad background examining problems with fresh eyes. We see this in many fields, not just design: medicine, business, art, psychology, to name a few.
As design moves into new areas and the products we create become more personal and adaptive, designers are going to have give up some control and be more of an integrator of ideas. But this too is a design problem. How do you personalize something for thousands or millions of users? You can't invite them all to participate. Someone has to stand up and say, "I'll design this damn thing."
Posted by Rob on February 29, 2004 at 11:02 AM
Regarding genius: I'm not sure what to say except that I have yet to see any real evidence that it exists, at least in this space. Certainly people's minds work differently, and some people have more of an affinity for coming up with interesting new ideas than others. But this doesn't necessarily mean their ideas have any more probability of being useful.
We humans have a tendency to gravitate towards leaders, and we tend to bequeath these leaders more ability than they might necessarily have. I'm guessing that some great designers, artists, scientists, etc. are really just fairly ordinary people who happened to come up with a few really good ideas and became famous for it. There's nothing wrong with this; they've made a difference, as you say, and that's what counts. But I'm leery of calling them geniuses without more evidence that this is truly an innate characteristic.
Regarding managing user participation: I agree that this is a hard design problem, which is why I believe the idea of involving users and facilitating their own creativity does not diminish the role of the designer in the least. And of course we cannot involve everyone, so we must have methods for selecting representative users to participate directly in the design process, and figure out some other more lightweight method to involve the rest. And, as usual, the same methods probably won't work for all design problems. With some problems its probably more important to involve users in the design than others. But I don't want to close off this important avenue for design inspiration merely because we designers believe it is "ours" and refuse to share. That's what I'm afraid might happen.
Email Rob:
Email Rob: