What my friend calls “Designing with Others” I just call “Designing”. My design training and self-study has taught me that when it comes to the design of technology within large organizations, there is no other way to do it – so I have never really considered that design could be done by just me. I think that this is especially important in my situation, where I am the sole designer responsible for the UXD of entire products – including everything from user research to concepts to visual design to the final design deliverables passed on to the development team.

Working on major products for a very large software company, I have noticed some interesting things related to the notion of “designing with others”. Frequently I encounter scenarios where the development teams and product managers I interact with expect me to design the whole thing by myself – perhaps because that is the way they have interacted with UX designers in the past. Here are some of the things that I do every day to ensure that I don’t just sit in my cube and design stuff.

I have lots of brainstorming meetings with the product manager and development team – much more often than with other designers. The first few times I arranged brainstorming meetings or asked for design feedback from the product managers, product consultants, and developers I was met with perplexed looks. I know what they were thinking…“You are the designer, why are you asking me what we should do?” or better yet, ”Why aren’t you talking about this with the design team?” The answer to the second one might be specific to my work environment – each product typically only has one designer on it. Since my fellow designers are much less familiar with my product than I am, the feedback they are capable of giving often only falls into superficial territory – preferences about fonts and layout – but nothing mission critical to the product. That’s why I need the product managers, consultants, and developers to help shape the product – not more designers.

After trudging through the initial hesitance, and now I have frequent meetings with “non-designers”. Some are scheduled formal meetings, but I also spend a lot of time running around the office doing impromptu little 5 minute brainstorms with different stakeholders, partially to get my questions answered as they pop up – but also to make my process transparent. I find this to be more effective than the weekly or bi-weekly “design dumps” that only allow the other stakeholders to see the work after it has pretty much been completed. It also gives me more opportunities to inject design language into the process with stakeholders, as well as ensure that all the roles that touch the product have a common understanding of where it is going. For me it is all about the frequency of exposure to the design process.

While in the beginning I was met with perplexed looks, in the past few weeks while working on a major new release I have often been thanked by the development team and product manager for making their input a huge priority in my design process. This has ensured that the entire team of people working on the product feel a sense of ownership for it. While I sometimes sense that they don’t like how many questions I ask or how often I pop in and say “Hey, you got five or ten minutes to work through something with me?”, I know that the benefits of having everyone contributing and understanding outweighs the small interruptions throughout the day. It is less than ideal, but worth it in the long run.

And as I seek to inject the organizational process with the language of design, I make sure to learn the language of business and development and refer to it when appropriate. Let’s be real about it: I am 1 designer on a team with 10 programmers, 1 lead engineer, and 1 product manager inside of an organization with hundreds of programmers, dozens of sales staff, and 11 designers. My success lies in my ability to navigate the language of business and development, and find ways to make design resonate with them in their own terms. I have heard this called “rational resonance.”

All of the preceding stuff relates to including stakeholders to make transparent the language and rationale, but the notion of design accountability (in the sense that an act of creation is oftentimes a leap of faith) is a bit trickier. I seek to acknowledge and make clear (quite often) that we cant get it “completely right” – and seek to build consensus about what we consider to be “unknown.” At times like this I cease trying to design the “perfect vision” and instead attempt to provide design deliverables that can be built upon once it is released and the “unknown” becomes the “known”. Generally this is something you want to happen as much as possible in a prototyping phase, but in organizations that don’t have “perfect” design processes, there isn’t always time for lots of prototyping.

I was just saying today to a fellow designer that I can’t wait for the next release of my product so I can document and reflect upon everything we did right and what we did wrong. I plan to discuss our process with my team to help all of us understand what can be anticipated and what can’t – what we should expect to fit in our realm of design accountability and what can’t. (For instance, I hope to use this release as an opportunity to point out the problems that could have been avoided if we had prototyped things first, or if we had accurate user data – making them things that fit in our realm of design accountability).

But as my friend said in his post, the implications (and before that the DEFINITIONS) of Design Language, Rationale, and Accountability are too complex and context-dependent to put in a single blog post. Nevertheless I will continue doing what I can to create an environment where good design is recognized and can be implemented.

In an organization responsible for building and selling a digital/software product, there are hundreds of people who affect the final outcome.

The user’s ultimate experience of using a product is a combination of what marketing says, what product managers plan, what the engineers code, etc. I (as a UX designer) can neither account for nor control all of that. But I can help be a beacon for UX values, so that when the people in those roles that fall outside my immediate sphere of influence go do their jobs – they do so in a way that creates a more positive user experience.

My job title is User Experience Designer, but I can’t “design” the user’s experience and then pass it along. The current expectations of such a job title definitely pigeon-hole me into wireframes, style guides, and workflows – but my real responsibility is to be a beacon of UX values. To me it is the difference between truly caring about doing what it takes to make the technology provide a better user experience, or designing the best solution that I can come up with based on my own individual design understanding, throwing it over the wall to the team that will build it, and crossing my fingers.

Bottom line: UX design values can’t just be a piece of the organization and process. The entire organization’s process must be beholden to UX design values – and that can’t be done by one person.

“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.

It also seems to me that speaking of design as a shaper of behavior or rhetoric puts the emphasis on the wrong place for most practical industrial or interaction design work. I guess I align more with Christopher Alexander’s approach in Notes on the Synthesis of Form and A Timeless Way of Building–that what we design should fit, not so much change or shape, the way people already behave or want to behave, and it should only be rhetorical if put to ends that align with the good of those being designed for.

Thank you J. Ambrose Little.  People come first.  Our values as designers will undoubtedly manifest themselves in our work, but we design things, not behavior.  We can only design for behavior.  Now I gotta go read Jon’s book.

The transformative powers of repeated viewings were incredible. I had entirely different experiences when I viewed the game through different phenomenological perspectives. The first time I saw it as just a MMORPG player. When I first watched this video, I was distracted by the medium. All I saw was World of Warcraft characters, and attached to them every stereotype and bias that exists about World of Warcraft players, my understanding of the culture of MMORPGs, and the pop culture phenomenon that is the game.

However, after repeated viewings the “World of Warcraft-ness” started to fade away, and I realized that this video is very compelling. The second time I saw it as Chad with my particular history of knowing people who have died and the beginnings and endings of relationships in my life. I even noticed that when I was writing my notes from watching the video, I never referred to the character in the video as “he” or “him.” I kept writing the word “I” or “me.” That was quite a powerful realization.

Then I started reading the various comments and I saw someone who said it reminded him of when his mom was killed by a drunk driver. In my next viewing I pretended that my mom had been killed by a drunk driver, and I was surprised (and a little frightened) at how easily I was able to envision that scenario. Throughout all of these viewings I felt real, genuine pain. It grew even worse when I kept reading the comments about all the other types of loss that people associated with the video: breaking up, moving away, death of a loved one, losing touch with a childhood friend, someone cheating on someone else, or watching a sick relative slowly get sicker.

The sadness and tragedy of life were made even clearer by the insensitive and frankly assholish comments that are interspersed amongst the genuine comments. For every heartfelt comment there is another where someone is making fun of anyone who got something out of a “stupid video game.” There is much to be said here about internet culture, how machinima is viewed amongst other forms of expression, or how this particular video is grouped in with funny and ridiculous other WoW-inspired machinima. But that is the structuralist and semiotic stuff for later.

With all my new lenses for looking at things, I am slightly overwhelmed with things that I can say about this video, not least of which is that this video is definitely not what Blizzard had in mind when they created World of Warcraft.  But I have come to an interesting realization recently, and it is this: It isn’t our ability to say all these things that is valuable. It is the fact that we have noticed new things and in doing so are able to have richer experiences.

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.

While those are admittedly straw-man statements, I feel that they do have a hint of truth in the field of HCI.  I myself feel that way at times, but I am beginning to understand what I will gain from a deep study of aesthetics and critical theory.  The goal isn’t to replace all of the inspirational pictures on the walls of the design space with academic papers, but to provide me (the designer) with new perspectives to view those pictures through.  By that I mean that the point of this approach (and of this class) isn’t to turn me into a philosophy-spewing humanities fueled machine, but to internalize some of the material so that I cultivate better designerly judgment.

I tend to think of incentives as “the path of least resistance,” and these incentives are key when thinking about design, especially the design of sustainable systems. I will use an example from my own life: recycling.

I want to recycle everything. However, I don’t consider myself to be a “green” person, and I am not really motivated out of guilt or because I want to save the planet. I want to recycle because it makes sense. I tend to be motivated by logic and waste isn’t logical to me. However I am also motivated by efficiency, the same as many people in American culture these days.

But the apartments I live in don’t have recycling bins anywhere. If I want to recycle, I have to separate all my trash in my apartment. I don’t have a vehicle, so my options are to get a friend to let me pile up all my garbage in their car and take it to the recycling center across town. With this system in place, there is no incentive (path of least resistance) for me to recycle.

Conversely, when I am at school I recycle every can and every piece of paper because there are recycling bins everywhere. Since I find it illogical to not recycle, the path of least resistance at school is to recycle. The recycling bin is located right next to the trash. There is no reason why I wouldn’t recycle it.

Then back at home everything goes into the garbage. This is because there is no incentive for me to go through all the trouble to recycle outside of my own altruism. And sadly altruism is not the best incentive for most people.

I feel that design for sustainable systems suffers from not understanding this. Many projects and ideas that I have been presented with since I have been studying human-computer interaction design have focused on raising awareness. The assumption is that if we design systems that make the amount of waste visible, people will be more aware and will waste less. While this will certainly make a difference, it is not the answer that is going to help change an inherently wasteful culture.

For certain the tone in our culture is shifting, and being “un-green” will exude a poor public image. Perhaps there will come a time when being seen as “un-green” will carry such a bad connotation that the path of least resistance is to do the eco-friendly thing. But we aren’t there yet. That is why we need to understand that for most people, the path of least resistance is to toss everything in the trash.

Maybe we could focus on changing the system based on incentives. My current system has no incentive for me to recycle, and I actually want to. This could be solved by any number of recycling programs (bins, more recycling centers, recycling pickup, etc.), and eventually they will be implemented. When thought of from the point of incentives, or the path of least resistance, there is no way I can be expected to recycle within my current system. The same could be said for many others within many other systems, and a deeper understanding and appreciation of incentives may be key to designing better systems in the future.