“If you consider Human Computer Interaction Design to be “designing the relationship between humans and technology, then to do it well you need nothing less than an understanding of the depths and expanses of the human condition, and the ability to work in situations of co-creation. To understand the human condition you need to understand experience, language, culture, and emotion. To understand co-creation you have to understand how to enable, educate, and empower others to design.”

“When attempting to teach someone something new, it is better to say “We aren’t here to change you, but to challenge you.”

“The principles of design thinking are the keys to organizations solving problems that arise from disruptions.”

Interaction Design is about:

• thinking critically
• making something from nothing
• getting stakeholders to evaluate their own risks and goals
• focusing on people, understanding them while you navigate the process and learn how to listen
• knowing your process, making it transparent, and creating a situation in which everyone takes part
• designing for the user to promote inward-facing dialog in the organization

Here are 3 different levels of what human-centered design could mean, each of which is important:

• looking to the user for inspiration of design instead of the technology
• looking to the user for the evaluation of good design, usability, and “rightness”
• cultural theory and cultural critique methods to “humanize” the process

“HCI/d relies on understanding people. You can’t design or do anything of value unless you understand people first. Get the right design before you get the design right.”

That was actually quite enlightening for me to put all that here. I think I actually synthesized a bit for myself. And I got some Twitter fodder.

“Some people read books, some write or share their experience or thoughts on blogs or by simply reading some famous author’s blogs to upgrade their knowledge. Share your most preferred blogs or books to improve and update latest trends on User experience.”

This is a common question to find on LinkedIn or on forums like IXDA. However, I typically find that these are the wrong kind of questions to ask, especially since the question is concerned with “the latest trends.” Also, responders almost always view user experience or interaction design as web design, software usability, or graphic design (a dilemma that isn’t likely to go away anytime soon). Indeed it does include these things, but I feel to do it well one must take a broader perspective of what it means to design technology. In any case, I thought my response to this question was decent, so I decided to re-work it here.

I am about to graduate with a master’s degree in HCI/d from Indiana University, and from what I have learned during my education, work, and research is that the key is to first define what you mean by “experience” and “design.” Admittedly this is a bit biased by my education, but without evaluating how you are defining these two words, it is easy to be at the whim of whatever flavor of design that IXDA or boxesandarrows is tossing around at the moment. There is a lot to read or listen to with regards to both of these concepts, and the definitions of the two could fit on a spectrum with “build a GUI interface in Photoshop” on one end, and “understand the fundamental components of what it means to be a human being” on the other.

For me, I view experience as holistic, all encompassing of culture, language, and people. Design I view both something fundamental to being human, as well as a way of approaching complex problems. It is something that when understood can be a powerful tool for creating meaningful works.

To be a good interaction designer, you need to be able to navigate multiple perspectives, and walk the philosophical line between natural science and social science. And it isn’t easy. If I have to point out some people to read, then Jon Kolko’s Thoughts on Interaction Design, Bill Buxton, and Elizabeth Churchill are a few good reads for a rounded intro to interaction design. Erik Stolterman and Elliot Eisner are perhaps my favorites for design in general. For understanding experience, I recommend Heideggar, Gadamer, and McCarthy & Wright.

But ultimately, it isn’t the reading or the fancy philosophy talk that leads to understanding. Reading can help us to fine-tune our perspectives and the lenses that we see through. It is up to us to put our knowledge to practical use, because only in doing do we truly start to understand.

So how does someone improve or update their knowledge on user experience design? Read anything that blows your hair back, but don’t think that you can passively take it in and “gain” the knowledge you need. Start with yourself. Learn to think beyond yourself, don’t be at the whim of trends, and be humble. Then get out there, practice designing, and be reflective about it.

Most designs are the result of a process of co-design, involving several stakeholders and people directly involved in the creation of something. In this process, there is a constant state of exchange between the people involved. Effective communication is important at all stages, but this isn’t easy to accomplish. There are many things to consider, including the different roles, perspectives, and communication skills of people, as well as how we even might measure what “effective” communication looks like.

I have been trying to work through some of this in the hopes that I might define what “effective” means in this context, and in the process become a better communicator myself. I believe to understand this we must start with some basic premises:

Communication exists between two parties, and this communication is done via give and take, or for the purposes of this post, via “talking” and “listening.” In describing them this way, I should be clear that I do not mean them in only the physical sense of the words. I also mean them in the metaphorical, or abstract sense of the words. For instance, a picture can “talk to me” because it conveys messages to me. Following from this, I can also “listen to the picture” by paying attention well enough and being equipped with the ability to interpret its message.

All throughout the design process, whether showing sketches to other designers, listening to a user tell a story about an experience they had with a piece of software, or looking at a programmer’s model of the system, everyone employs various methods and tools of communication. We do this whether we are trying to communicate an idea to someone else or to ourselves, or form ideas with someone else or with ourselves. This could be thought of as perhaps either describing the idea or forming the idea, which arguably are inseparable from each other since in describing the idea we also give form to it. In this the act of communication is simultaneously an act of generation and communication. We do this with words, pictures, diagrams, etc. Often this is called a sketch.

A semiotic perspective tells us that basically anything of these things we use in the design process to communicate ideas or value to others could be seen as a “sign” or “text”. Each representation is made up of other signs, connotations, and embedded values that need to be interpreted by others. Everyone in the process brings with them their own life experiences that provides them with unique perspectives and understandings. This is why communication is so vital to the process, because we all have different pictures in our heads about what the design is and what direction or form it should take.

It is here that I think I may have hit on the most important thing to consider when it comes to communication. We are all individual people with individual life experiences. If we understand this to be true, then we understand that every perspective on an issue is valid. This is different than truth. In communication, truth is a matter of subjectivity, and in order to effectively communicate one must accept that everyone’s perspective is a valid perspective to have.

We can disagree and we can discuss, and indeed we should. However, disagreements and discussions are much more likely to bear fruit if everyone recognizes the validity of others’ perspectives on the issue. I believe that this is what makes a person able to truly “listen” to what another person is saying, whether they are saying it with words, pictures, diagrams, silence, etc. So when a “non-designer” (what does that even mean?) comes to me, I won’t dismiss their input because they haven’t been trained to think like I do. When a programmer questions my design, I won’t see it as a hurdle, I will work to explain it so that we both understand it better. When someone tells me they don’t understand why I did something I won’t play the “I-am-the-designer-so-I-know-better” card.

How will I do this? First, I will work to create an atmosphere of co-creation in which everyone is involved in the design, not just people with the word “Designer” in their title. Second, I will recognize that everyone has valid input – and work to understand that point of view so that we can have exchanges instead of arguments.

I am a design-thinker before I am a designer. I don’t come with design-baggage.

I only stayed for two hours, but what I got out of it was that “Acme” wanted me to know that they have created an entire design and development process for me.  It just so happens that every single step in that process completely relies on “Acme” products.  Additionally, the new software tool I was supposed to be learning was being presented as the solution to the visual/interface designer-developer communication gap.  No mention was ever made about actually talking amongst designers and developers, including a wide range of people on your team, or cultivating an open and communicative attitude in your business. No, with this new software tool, as a designer you can keep thinking the developers are a bunch of nerds (this is what “Acme” actually said numerous times in the session), and just do your work and pass it along.

Despite all this there was still something even more sinister at work: they spent two hours talking about the tool before actually opening up the software and using it.  This was to ensure that we thought about the tool “properly” before starting to use it.  This is what bothered me the most about the session, and it got me thinking about all the tools that we use to design things.  We as designers have the luxury to decide on our own how we will think about a tool, how we will fit it into our design process, and what our process looks like.  I feel that in their efforts to force a process on us, companies like “Acme” are just reducing designers and developers to cogs in a machine.

Design is not a machine.  No matter how much somebody wants it to be predictable and safe, it never will be.  Design is messy.  Design deals with wicked problems.  Design involves judgment.  This doesn’t sound so good considering everything that might be at stake with a design: time, money, safety, ideologies, etc.  However, the most anyone can hope for is that designers use tools and choose processes deliberately and with designerly rigor.

“Hmmm…potatoes.  They cut them here to make the fries.  I don’t see any way they could cut them by hand.  They must have a machine.  But I don’t see any machine that could cut them into fries.  Well, there is a machine there on the counter.  No, that is a slicer for sandwich meat.  Ok, then where is the potato french fry cutter?  Well, I don’t know what a potato french fry cutter looks like.  But I am a designer, so what do I think it should look like?  What kinds of design decisions go into making that machine?  Do they use human-centered design methods when making that machine?  Are the designers of that machine more concerned with human factors rather than experience design?  Do they try to design for efficiency, or do they try to make the use of the machine satisfying, like when Bill Buxton talks about the experience of using his juicer?  What materials would they use for that machine?  Would it be something obvious, like steel, or would they use something different?  How would the potatoes come out?  Would it be like a cannon, or would they sort of just squeeze out slowly like those old Play-doh machines that you could make fries or noodles out of?”

Then my mind snapped out of it and I explained to Matt why I had that weird look on my face for the previous few moments.  We both laughed because this happens all the time now that I have been in a design-oriented Master’s program for over a year.  It can be maddening at times, but is still funny to think about.

It is kind of like when you recover from a sinus infection or a cold.  After a week or so of not being able to hear, smell, and taste properly, once it is over the world seems richer and your senses are more acute.  Now that I am thinking like a designer, my brain is now more acute and sensitized to the artifacts in the world around me.  It kind of feels like a superpower.

And by the way, those fries are delicious.  Only slightly less delicious than the fries at Five Guys.

• Clear sketches lead to clearer communication.  Both my knowledge of what sketching can do for me as a language of thought, and my abilities to sketch what I am thinking still need some serious work.  This is something that I have been putting further effort into practicing.
• Personas are a great tool when you can’t do in-depth interviews, ethnography, and contextual research.  They obviously can’t truly stand in for a real person, but they can still be helpful.  Also, any of the designer’s tools (in this case personas), can be put to use in slightly different ways depending on the designer, the company, and the context.
• It isn’t necessary to add more features to accomplish design goals.  We incorporated many features in an attempt to change behavior instead of adapting the design to fit with existing behavior.  For instance we might have let the user turn the thermostat way up or down, but have the thermostat keep the temperature within acceptable ranges.
• High-fidelity prototypes can make it more difficult to get proper feedback.  We did ourselves, our design, and our users a disservice by going straight from concept to high-fidelity prototype.  If we had used a low-fidelity prototype we could have helped our test participants to focus on the concept of the design instead of the little details, and ensured that they were less inclined to hold back criticism.