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 1^st person perspective and stepping back and applying an outsiders point of view, your own as a designer, a 3^rd 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.

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.

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.

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.

Designer & Developer Collaboration -hmm, yeah, maybe

Stop, stop, stop. Just stop. Step back. Breathe. Deeply. Again. Now let's talk. Designers are not developers. We are not and do not want to be. Yes, designers should know the material they are working with an in the case of interaction designers the material is in some way and to some extent code. So as a Designer you should understand some code and it helps even more to understand how it comes about. It always helps to appreciate the work of the people you work with.

But it cuts two ways.

And I am sick and tiered of the oversimplification of the designer job that reduces it to implementation and production. This is the simplification that runs through articles such as Google Enters Designer, Developer Fray, Designers who also develop have more power, and to a certain extent The New Iteration. In Bill Buxton's words, all of those articles focus on the part of the project where you get the design right, none of them pays any attention to the time spent getting the right design.

My beef with WPF

In my understanding WPF has two promises:

1. A better UI platform with higher engineering efficiency and capabilities of a richer UI
2. That developers and Designers can work together on the same artifact.

Let's get #1 out of the way. WPF has delivered on number one to an B+. With some of the improvements in 3.5 and planned for later we are nearing an A, and once we have real time bitmap effects I will gladly hand out the A+. Great job all around and just looking brighter and brighter.

For number two however, I am less impressed. To be fair, I think WPF and Blend has set themselves an impossible goal. How do you make something that is a real development platform easy to use for people who by-and-large cannot code. My most mundane example of where the platform sticks it head up in blend is the difference between items controls and normal controls. Some can contain one element, others can contain many. And well, just the whole concept of controls is not that hard to understand, but still is slightly foreign. And then there is the difference between "content" and "text" properties that you just have to know something about the platform to understand why those are different. Not so different form HTML + CSS just much larger and more complex. Try for instance to compare writing CSS with XAML templates and Styles and yell when you get to RelativeSource RelativeParent And remember how long HTML has been around and that you still have many designers working with web who work in Photoshop and Illustrator and never touch HTML. Yes, I know, developers don't like that, but this is al part of not trivializing design. Not even the 'get the design right' part.

Blend is a good application. It is far from complete but i strongly support any team that finishes an area before they move on to the next and I think the Blend team does that very well. It is however still an application for implementation. At least it is for now. I hear they are thinking about making it better for prototyping. When asked when I use Blend for my design work I usually respond that "I don't". Which is only a half lie. I do, but only for the implementation oriented last part of the design process. People are usually surprised because they have heard WPF should be a great designer's platform and so they assume that the deliverables at the end of the project = the design work. Which would be the same as saying the code = the developer's work which would leave out all credit for any kind of architectural thinking.

What grade should we give WPF for the designer + developer collaboration?  I am tempted at a very low score, but maybe that is unfair. Maybe what should get called out instead is that they grossly oversold it and yes, under delivered. And I think more people should read Karsten Januszewski & Jaime Rodriguez white paper and use their categorizations for the roles designers and developers play in a project. A lot of misunderstandings between developers and designers and between management and ICs could be avoided if people were real clear about the roles they expect in the project, and if people would understand that all this talk about WPF is about the last stage of the design process. It is what you start working with once you are done with the hard part; getting to the right design.

Interviews with UX pioneers

http://www.adlininc.com/uxpioneers/ 

Ben Shneiderman, Alan Cooper, Cliff Nass, Jakob Nielsen, and Carol Barnum.

What about Phones

A while back there was a lot of research around the BRIC countries. Brazil, Russia, India, and China. Now Africa is popping up more and more in the news as a future growth market. Yet I don't know what our Server vision outside of North America / Europe. Do we not see a difference? Will the explosion in mobile devices be felt there first? Craig Mundie will do his part to make it so: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9084018&intsrc=news_ts_head