Sunday, August 31, 2008

Humans versus Personas

I try not to use the term ‘user’ anymore. I really strive to not use it. Instead I talk about ‘the people we design for’, or about the ‘people who will use our software’. I think the term ‘user’ implies that these people are defined by using our software and I think that leads us to design for them as if that were true. As a concrete example, every time we talk about designing for the application being maximized to the screen, we commit the hyperbole sin of assuming using our software is all these people do.

The word ‘user’ is also symptomatic of what I don’t like about personas. Personas are made up people and I have a hard time relating to them. I am sure they are made up of real user data, but they are made up from the point of view of someone designing for them and usually make us, the product team, look more important than we probably are.

I like designing for real humans because when all goes well, it helps these people, it has a positive impact on their lives. I think that is the main reason I have a hard time with personas. I can’t impact them, I will never make them have better lives, and they will never call me up or write a blog post about how our product is better than what they had before.

Design as a Process of Becoming

Donald Schoen calls design is a dialog with the material, a dialog where you shift from immersing yourself in the problem and standing back to get a perspective on your work so far. A sinus curve. In, out, in.

But design is not only a dialog with the material; it is also a dialog with the people whom you design for. A process of on one hand understanding their point of view and on the other applying your point of view to the problem. A process of becoming them, taking on your customer’s point of view as your own. It is true; you should not be designing for yourself. You should strive to become the ones you are designing for and then design for yourself. In this way of understanding what design is, the process can be described as acquiring and using a 1st person perspective and stepping back and applying an outsiders point of view, your own as a designer, a 3rd person perspective on the problem.

This requires two orthogonal qualities. As designers, we need empathy to understand people and we need director skills in order to impose our view of the world. Without one the other is useless. If we don’t have empathy then our point of view will be just ours. We will construe the task we are designing for on our terms and we will deliver something that is most likely strongly us but with an inadequate understanding of the real task and without regard for the human beings who will use our solution’s real needs and desires. On the other hand if we have only empathy and no point of view or the will to impose it, then we are not designers. Design is by and large about what the world should be like. And the strength of the ‘should’ is determined by our experience and vocabulary. I believe that this is what we primarily bring to the table, an ability to envision the world being different, but again, without the empathy that will be a hollow vision.

To some extent this may sound like method acting. I think the difference is that in design it is crucial that you also step back and get the outsider's perspective.

Tuesday, August 26, 2008

Fidelity vs Intention

Bill Buxton has given us a language to talk about Design and various stages. He has introduced the distinction between getting the right design and getting the design right



Buxton has also talked a lot about hand drawings and sketches. Per his yellow book the difference between a sketch and a prototype is not the fidelity but the intention and what it communicates. I personally talk about it as describing "what could be" vs. "what should be".



I think however that there is a tendency to grasp on to the notion of hand drawings (or finger paint as I heard in one presentation (sic.)) and talk about it as if the are the solution to all early design thinking. I would suggest that they are not. Different problems need different solutions and fidelity does not equal done-ness


I am all for doing the right thing given the phase of the project and the problem at hand. But I am very much against lack of critical thinking and dogmatism. Communicating something through a hand drawing does not make it a sketch. I know people who can draw rectangles and scribbles but at the exact relative size so they can make very precise specifications for placement by hand and I know people who can express crazy far out ideas pixel perfectly.

Sunday, August 10, 2008

Can you design anything? -Vocabulary vs. Process

I have had this conversation with another designer on my team a couple of times. The kind of conversation that goes something like this: "...and then we needed to do x, and you know me, I can design anything, it is all just design, so of course I did y...."

Over the past couple of weeks I have been thinking about how much we mean when we say "anything". And why we would say "anything" at all. Could I design a ship? a spaceship? a car? a sandwich? My basic answer is going to be "yes" but with the caveat that it would take me quite some time to design some of those things. More than it would certain other people.

To some it should seem completely insane that I would even answer yes to some of those challenges, but I think I could because the design process is fundamentally the same. You need to go through the same steps regardless of whether you are designing a building or a piece of software. You do however need a different vocabulary depending on the domain you are designing within. Since I do not have any sort of vocabulary for boats and a very limited one about houses, my designs for those would either be naive or take a long time because I would have to build up the concepts and experience within those domains in order to go beyond layman terms.

A vocabulary is like a language. It is the concepts you can use to talk about a given domain. For software words like 'direct', 'desirable, 'predictable', and 'fluid' are part of our vocabulary. Part of knowing a language is also knowing its grammar which is like knowing which solutions to bring to a problem and how to stitch them together to make a whole. For us this is knowing the "dual listboxes" pattern for creating a subset from a static list and being able to extend that to work for a dynamic list/multiple sources. Or being able to recognize that in a certain situation that is not the right pattern to use.

Becoming a designer is by and large learning the design process and learning the vocabulary of at least one domain. Once you are fluent or at least reasonably 'well spoken' in one domain, acquiring the vocabulary of a second domain becomes much easier. Now you know what it feels like to know a design language, so you will have a tacit understanding of what you need in a new area. The time it takes you to learn the new language depends upon how close it is to the other languages you know and what other knowledge you can draw upon. I have lived in a few houses, been in quite a few, traveled a bit, and seen houses from different ages. I am still a layman when it comes to architecture, but should I decide to pursue that field, I will be able to draw on that knowledge while I learn the language of buildings. Should I choose to try my luck at spaceships, the amount of knowledge I can bring along is significantly smaller.

When my colleague and I say "anything" we usually mean "anything digital". Within that domain we have a rich vocabulary and it does not matter if it is a reporting service, a filter design, or an information site. They are all part of the same set of 'things'. Should you however ask us to design a house, you may end up with something quite ordinary, and you may even have to be lucky for it to work properly. Or else you would have to give us the time to learn the right language.

Monday, August 4, 2008

The Email Interface vs. Email as a Bridge

"It is just like email. Make it like outlook". Those words have been said in more than one executive meeting and you and I have both been in discussions where someone ended the argument with "well, that is how it is done in Outlook, so we must do the same to be consistent".

But few make the argument that you should simply not build any UI but just use email. Now, this is different from for instance Dynamics CRM, Dynamics Business Contact Manager, or Dynamics Small Business Application that all build additional UI inside Outlook. Khoi Vinh instead writes about companies that don't make additional UI, but use email as a bridge, an way to exchange and collect information. The idea is to build on something people already use and already has their own workflows for.