One thing designers aren’t often taught in design schools is how to work with and respect the other functional areas that you’ll work with on software. For the most part, the attitude coming out of HCI or related programs is a strong belief in design as being a savior to the rampant problems of bad experience with software (a belief that can easily become arrogance). Once you are out of design school, you will then find blogs that say more of the same, often either writing about ways around constraints and frustrating developers, or touting new methods for how to instill the value of UX into one’s organization. In a way, we are trained to believe that design is everything only to find it can be quite a hard sell in the real world.
I’m not writing this to criticize design schools. In fact, I think this is probably the way it should be. Designers should leave school feeling inspired and ready to take on some of the wickeder problems out there. The problem, I think, really lies in the defensive nature the UX community often takes when confronted with obstacles in corporate and consulting environments. We believe we can change the world, only to find that our designs are hacked by developers or simply ignored by our clients. So we get upset. We blame software developers. We blame product managers. We blame “the corporation.” If we haven’t quit our job to find a company that “gets it”, then we try to find better ways to “sell” our designs. Or change the culture. We try anything to get the other functional areas to understand just how valuable we designers are.
Fundamentally, this “design first” attitude is self-centered.
How often do you think about the needs and motivations of your other functional areas? Unless someone genuinely has it out for you, it’s safe to assume all functional areas working on a product want the same end result: a product that is useful and a pleasure to use and makes money. So why do we act so differently or above other groups? Mostly, I think it is because each area has different incentives that yield different motivations along the way. Software developers, for example, are largely risk managers. They have deadlines just like any of us but they have the ability to actually break the product you’re building. As a result, they will inherently be hesitant towards any changes that they are unsure about. This manifests itself to designers as “scoping out the important stuff” or “being conservative.”
Another example (at least from my experience at Autodesk) comes from Quality Assurance (QA). Their incentive is defect counts (simplified). They are paid to pick apart the product. As a result, you may find them asking very detailed questions about designs–things you may find either inconsequential or downright annoying. They are only doing it so they can do their job better. These are just several examples of the ways different functional areas of a product development team can have a perceived negative effect on your ability as a designer.
Everyone involved in a product has the same end goal but we have different ways of getting there. And while there is nothing wrong with thinking that design can save the world, it’s not the best approach or attitude to take to really be successful. In the above examples, you could increase your chance of items not getting scoped out by planning better and working with developers or software architects earlier on in the process. You could help QA by being aware that the amount of detail they need from your specs may be more than you care about (a nice by-product is that your design will improve).
If my experience over the last 5 years has taught me anything, it’s that lecturing and selling design are easy ways to meet resistance. But respecting and empathizing with the other teams you work with are easy ways to find solutions. Helping others get what they want will help you get what you want.
July 11, 2011 10 Comments
I’ve had several experiences with user researchers on the products I design. At first, my design team had a dedicated “usability engineer” that worked on our team. That person has since moved on, leaving us designers to conduct research ourselves. Over the past year, we’ve used two different user researchers. One was an outside firm and the other someone we’ve brought on to our team recently. These experiences prompted me to tweet recently about my thoughts on how user researchers should influence the design process—specifically in the preliminary research phase. 140 characters didn’t allow me to express myself, so I’m taking this opportunity to clarify my thoughts on what a user researcher’s role should be in the design process during the research phase. There are a lot of things I could discuss in the area of research and design but I want to focus specifically on the area of what a user researcher should be expected to deliver to a designer.
Each company has a slightly different design process. For the sake simplicity, I see them as research (or discovery), conceptual design and prototyping, detailed design (spec), and usability testing. My company has had usability engineers with an emphasis towards the final usability testing phases, but more recently I’ve been lucky to get the opportunity to work more with user researchers. Their roles throughout the product lifecycle are still being defined, but I want to speak specifically about their role in the research ,or “discovery”, phase of the design process.
I mentioned the basic design workflow because I firmly believe that it’s ideal for designers to be active in each phase. But with the introduction of dedicated user researchers, this becomes more difficult. How much of this phase should be owned by the designer and researcher? In my current project, the researcher dictated the protocol and recruited potential users for site visits and interviews. Designers on the team gave input into the topics to be covered in the field. This process worked well. The struggle has been figuring out what to do with the research and who should do it.
The final deliverable from the researcher for my current project contains not only high-level summaries of user behavior and preferences (which I’m okay with), but an organized series of design recommendations. This I do have a problem with. First of all, researchers may not necessarily be equipped to make such design recommendations. Sure, a lot of us went to the same design school with researchers. But I bet you can think back at which ones were better designers and which were better researchers. Most design curriculums allow the freedom to drift towards either one. This means two people that have the same degree might actually have completely different skill sets. I for one know several of my design peers who are dedicated user researchers. The analytical minds are best at researching, the creative minds are best at translating that into a design.
Second, particularly in the case of using research firms, researchers may not have the product knowledge that you have. This is very specific to my experience because there are so many variables involved. For one, I work on software that’s been around for years. It’s also very domain-specific. As a result, this may not be such a big deal for those in web design or those designing consumer software that may be easier to relate with. In any case, it’s a definite disadvantage in my line of work because the insights gained from user research are only as good as the domain knowledge of the researcher. If you don’t understand the long-standing cultural differences between CAD designers and GIS mappers, the quality of your insights is diminished.
Last, making design recommendations as a direct output of research circumvents the creative process that serves as the foundation for any design field—the ‘magic’. I believe all designs should somehow tie back to research findings, but design should not be dicated by the findings. In other words, if I’m given a design recommendation, then what exactly is my role as a designer? If a design recommendation is meant to be a guide for the designer, then where’s the opportunity for innovation? Design recommendations seem to marginalize the role of the designer.
So what should a researcher hand off to the designer? My friend Chatree stated it rather well, “[a] dedicated researcher should be giving analysis of findings rather than design recommendation.” In other words, a researcher should provide summary and analysis without any notion of a potential design solution in mind. The rest of the conceptual design process should be left up to the designer. It is his or her job to look at the research findings and determine what this means in the interaction design. This plays to the skill-sets of each person. The researcher focuses exclusively on analyzing behavior and patterns. The designer has the freedom to interpret this in a way that makes sense in the context of their expertise of the product. This avoids the researcher misappropriating the research and the designer misinterpreting the research.
Please feel free to express your own thoughts and experiences in the comments because I’d like to get a broader picture from other interaction designers and researchers. There are many facets to the role of research throughout the design process, so remember I am focusing only on the discovery phase—pre-concept. I’m interested in hearing about experience with dedicated user researchers, contracting user research, or how you (as a designer) conduct research yourself and whether you find it to be the best option. Also, if you are a dedicated user researcher, what works best for you?
January 27, 2010 9 Comments
Personas are talked about plenty that there is probably little else I can contribute to the discussion. However, I want to share a bit about my first official experience using this method in my design work. I say “officially” because were learned to use them in grad school but after getting a week-long training in this area at Cooper earlier this year, I’ve now realized how bad we were at the time. Now, I feel I have a better understanding of the usefulness and limits of personas. (not to mention the sweet Cooper University certificate to prove it For awhile I was skeptical of them–namely because I felt they marginalized the user into some wild estimation that gave the designer little insight. After all, I’m married to a cultural anthropologist and this is touchy territory. However, as I went through training I began to gain a different perspective on this method and its practicality. At the time I had also came across Steve Portigal’s Interactions column where he completely assulted this method and I found that this article and many others completely miss the point of Personas.
Personas, “when created correctly and responsibly” (disclaimer), are great ways for designers to stay grounded when designing features/products. Do they generalize users? Definitely. Do they cause you to lose some personal contact with your users? Somewhat. But, these can actually be good things. It’s entirely impossible for a designer to fully empathize with more than maybe 3-5 users. In fact, if you try to, the sheer difficulty in maintaining all of your users’ individual needs, desires and characteristics can overwhelm you to the point of ineffectiveness. Personas help generate patterns from users you interview so that you can actually detach yourself a little and concentrate on the characteristics that matter. In this post, I mostly only discuss the stage in Persona creation where the designer goes from research to characteristics to patterns. I don’t go into actually writing the Persona (I’m still too bad at this to write about).
As I used this method recently, when I got to the point of mapping user patterns based on characteristics I gleaned from 6+ user interviews, I found that it was difficult to really move forward until I was able to begin generalizing. I plotted my users on my characteristic charts and probably stared at them for 2 days before settling on a couple patterns. The reason why I struggled was because I kept looking at each individual users and thinking back on their story and workflow. Often, I opened my notes for them back up for reference. It was debilitating because I was struggling so much to empathetically process everyone I talked to. I finally started crossing out users’ names from my charts and replacing them with colored squares (btw, this is an advantage of plotting users in InDesign or other publishing software). It was almost emotionally difficult for me to really “let go” this way. I felt like I was throwing my beloved users, whom I cared so much for through their stories, out the window. Instead of seeing Steve and Susan, I saw green square and blue square. However, this release cleared everything up. The ultimate goal is to design interfaces that will satisfy most (all is typically an impossibility) of your users. By generalizing them, it freed me from the constraints of too much information and helped the common patterns emerge to the surface. This is the purpose of well-formed Personas, and this stage of the process is crucial. Any caring designer will hate the idea of “abandoning” their user for a characterization but it is the best way to ensure that you stay focused ONLY on the characteristics that matter for what you are designing.
I should mention that if you don’t believe the importance and value of generalizing users, just watch The Office, the “Survivor Man” episode. Basically, Michael Scott leaves to survive in the wilderness and leaves Jim to run the office in his absence. Immediately, the issue of empoyee birthdays comes up. Jim decides it’s stupid to have a bunch of parties so he proposes to group them into one. A great idea except that he lets everyone come and tell him what kind of cake/dessert they want and everyone’s request just piss everyone else off. It’s a disaster and Jim bails on the plan. The problem wasn’t Jim’s idea, it was that he had way too much interaction with his “users” and satisfying them each individually that it became impossible to satisfy any of them. Maybe this is only relevant to me…I digress…
Personas, in the very way that they force you to generalize users, help you sort through the particulars of your users. If you’re not convinced from my experience and an Office reference, then here’s a counter-example. A feature last year failed and had to be cut. It failed for many reasons but from a design perspective I always felt it was grounded in the wrong use cases. In short, several users were interviewed in researching the domain, but in talking to the designer, one customer would always stick out. Ultimately, it appeared that this particular user and their needs drove the design. The problem was that they had very specific and complex needs. As a result, the design accomodated these complex needs and completely alienated more common use cases. In the end, the designer empathized too greatly with a particular user and it was reflected in the overly-complex design. Persona creation helps prevent this. By finding the patterns that exist across users, Personas act as lenses for designers to filter out all the noise. Instead of referring to customers by name, we talk about the Personas because they are representations of commonalities across a broad user base. Steve and Susan may end up being Thomas, the CAD Engineer. But by focusing on Thomas, we are thus focusing on Steve and Susan’s common needs rather than one at the expense of another.
I’ve glossed over the intricacies of the Persona creation process. I simply wanted to focus on the aspect of generalization and how this can be positive for designers. You can read more about the stage I spoke about (from research to Personas) from Kim Goodwin. And of course anything else related to Cooper’s methods can be found on their homepage.
April 16, 2008 1 Comment
is not the phenomenon itself but the discourse surrounding it. Terms such as “global warming” and “climate change” are becoming marginalized in the mainstream media, and increasingly in product marketing. I see PG&E commercials in California with light bulbs talking about us being able to stop global warming and I recently heard an E-surance radio ad that discussed discounts on energy-efficient cars that “reverse the effects of climate change.” The fact is, it’s not that simple.
I’ve had many discussions on how the biggest hurdle facing environmentalism in this country is simply to burst into the mainstream. In other words, I have always thought the secret would be to “make environmentalism and sustainability fashionable.” However, I’ve also joked that this implies it may one day go out of fashion. In a way, as I see the increase in mainstream discourse surrounding this topic, we are setting ourselves up for a possible downfall. Climate change and global warming are still not fully understood. Even among environmental scientists from various disciplines, there is still much disagreement about its source. So, while we may be noticing more and more effects of these phenomena that perpetuate this ideology, one day we may see less noticeable effects. For example, we were supposed to have an even more active and deadly hurricane season last year than the devastating 2004 season-but this never happened. This year has again shown to be a disappointment in that regard (though, I think we are still on track for around 4 more hurricanes in the Atlantic U.S.). I’m not drawing conclusions from this that global warming doesn’t exist, I’m predicting that many other people will. It’s often that I hear in everyday conversation someone predicting climate through the weather. “It’s so dry and hot today, this global warming is killing me”. This line of thinking is not helpful.
I no doubt want environmentalism and sustainability to become a part of mainstream American culture and media. However, I want it to be for the right reasons. My observations worry me that we have created this mainstream movement on false pretenses-that global warming and climate change have been proven to be direct results of human activity. These pretenses may one day disappear, creating a backlash against the movement. If we all start driving hybrid cars and still suffer what we “believe” to be effects of global warming, the public may lose faith in the “science” and essentially give up (for lack of a less drastic way of putting this). This, of course would be harmful to the cause because any climatologist will tell you it’s impossible for people to judge climate change about what they can possibly notice on a day-to-day basis. These phenomena are trends that must be studied over long periods of times subjected to numerous models (which is difficult and is a large reason why there is still so much contention about the subject).
Of course, I have no real support for anything I’ve written but it’s been an ongoing and growing problem I have as there is more and more marginalization of scientific, environmental terms. Regardless of whether my fears are well-founded, I argue that the public needs to be better informed on what these environmental terms actually mean before we start acting upon them. Let media and marketing push us, rather, to become better environmental stewards but leave the science behind the movement to the scientists.
September 21, 2007 3 Comments
This question still bothers me today. When I had to create a portfolio in grad school, our only real frame of reference was graphic design portfolios. These are obviously good starting points but they are showcases for visual design. They often look beautiful but this is slightly out of scope for Interaction Design (ID). Visual design is a part of what we do but the interactions we design are difficult to illustrate in a presentation format. I recall many design presentations in school using the format of following a user scenario. This was a highly effective technique given in this format but doesn’t translate well to paper or web (feel free to disagree). And that’s the problem. Many techniques we use to present our designs in grad school are difficult to translate to passive mediums. In grad school, we are futurists: proving a problem exists, communicating a proposal to this problem and finally demonstrating what our solution might look like in this constructed world. So as interaction designers we need to decide what we need to convey in a portfolio and how to convey it. Here’s what I found employers wanting to see and how I went about solving this problem.
What employers want to see from a potential interaction designer:
- Design process – Almost anyone can display a beautiful product. What they want to know is whether you can do it again. You prove this by showing that you arrived at the product consciously and thoughtfully. Think of all the projects you’ve done with a team. If someone judges all of you by the finished product, you all look the same. But, you know there was someone who had little input. That’s why it’s important to separate yourself from the field by showing your design process. Note: I am not implying there is a “design process” as a universal standard-rather, you should be able to defend how you make design decisions.
- Design communication – Can you talk about design? Design is not art. You arrive at design through communication, collaboration and an articulate vocabulary (all of these pertain to art on some level too). Of course, there is corporate jargon you will have to pick up at any company but as a designer you should demonstrate your ability to communicate in a “design language”.
- Know your stuff – Okay, this one’s a little more crass but it’s vital. Whatever medium you choose to convey yourself to an employer, you better know your own material. You will most likely get grilled to some extent as to why you did certain things (not much different than a design critique) so it’s best to ensure you can discuss your stuff backwards and forwards. I got locked into an unanticipated conversation about my hard-copy portfolio in an interview and survived because I reviewed my projects. Some are 3+ years old and if I hadn’t reviewed what I did on those projects, I would have looked foolish. You study your material like your studying for a test.
Of course there are other things to consider in interviews but this is what I found specifically geared towards interaction designers. It’s a fairly new field without many of the axioms that other established field have to take into an interview situation. But the real question how can we (as interaction designers) accomplish the above in a design portfolio. This is an open question because I still don’t have a great method for doing so.
What helped me get my current job:
- Resume – No discussion really necessary here. Though, the format for interaction design should be slightly different. I think it’s perfectly appropriate to highlight some of your big projects.
- Blog – This will show that you are a reflective designer. You can give an employer a way to know you without meeting you. An employer may spend about 30 seconds thumbing through an online portfolio but you can really engage them with your thoughts on design.
- Hard-Copy Portfolio – We’re all pushed to make a digital portfolio, which is no doubt, beneficial. However, in two of my one-on-one interviews, I didn’t have access to a projector. Giving the employer this to use as a reference is powerful. People want to look at a printed page more than a digital one (aren’t you sick of reading this on the screen already). When you leave the interview, they have a physical sample of your work that they can’t as easily ignore.
- Digital/Online Portfolio – This is the biggest point of discussion. There is no good way to do it. Of course I believe this is a vital piece for an interaction designer to maintain (even after getting a job). But, given the needed material I described above, I don’t know how best to convey this. The link I provided above (and here if you’re lazy) is really effective on all fronts. The only problem is that everything in it is beautiful. We all know in HCI/d, we have created some flat-out ugly material. Stuff that’s much better to talk about than show. How can a designer reconcile this in a digital portfolio? Personally, I just had to omit some things, but I don’t think this is a long-term solution.
This is what I’ve found from personal experience. I’m curious to see what others might have found or any other proposals for how an interaction design portfolio might be constructed.
September 21, 2007 16 Comments
by Albert-Laszlo Barabasi
This book is technically outside the design realm but it has a lot of relevance to the field of technology and design. Barabasi talks about the growing field of network theory. He gives a good history of these theories and makes it relatively easy for an outsider like myself to be able to follow along. The book starts a bit on the jargon-side in discussing the mathematical theories behind networks and matrices. But he counters this by opening every chapter with a real-world example of the principles he is discussing. His anecdotes prove entertaining and useful in understanding how network theory helps to explain the world around us.
Barabasi see networks helping us understand the nature of order throughout many aspects of life–from genes to the Internet (which is what most of his work is primarily centered around). Briefly, the idea is that we must move away from looking at phenomena in isolation and seeing structures as interconnected networks. One example that comes to mind from the book is his retelling of scientists that were searching for a gene that causes manic depression in different areas. Each group of scientists found different isolated chromosones that were responsible. The reason, Barabasi argues, is that we should not view genes as isolated objects that control things. Rather, they work in a network and act differently under different conditions. This is aligned with my ideas of “systemic design” where designers should not isolate features of design but try to view them as a systemic whole (Malcolm McCullough talks about this in “Digital Ground“).
Barabasi also talks in great detail about the nature of networks and how the Internet is one of hubs and connectors. Again, he explains this well. At times the nature of the material makes it slightly difficult to follow, but he backs up the science with many examples. I often find many non-fiction books to be redundant but in this case the redundancy helps to understand the material. His anecdotes and exploration of the world of network theory makes it easy to abstract from. It’s easy for any reader to relate some aspect of their life to this new(er) way of ordering the complex world. More specifically it’s highly relevant at the dawn of the age of Web 2.0
September 21, 2007 2 Comments
I was just informed about Pangea Day, which is an effort to bring together films from around the world in order to “strengthen tolerance and compassion…to build a better future.” The idea comes from TED’s 2006 winner, Jehane Noujaim, who produced the call-for-participation video. The video itself is rather moving and the effort is attractive unique. The real power I find in this idea is its simplicity. As much as I read about global problems and work to create unique solutions I can’t help to be drawn to the simple ideas. Often we try to create complex solutions to complex problem but often that masks the underlying source. Is it possible that tolerance and compassion for other cultures can be achieved through films? Probably not. But the goal of this competition is to showcase videos that might serve as catalysts for future action. I will be intrigued not just to see what is produced by May 10, 2008 (the day of the worldwide broadcast of video submissions).
However, after watching Jehane Noujaim’s speech on Pangea Day’s homepage, I can’t help but feel like this effort is a bit misguided. From what I understand, the underlying motivation for showcasing videos from across the world is to bring a voice to the people. I will not argue that governments and media have long-quited the voice of the masses but I don’t know why there is this assumption that videos submitted by people will be any less-biased or agenda-driven. This viewpoint assumes that there is this global moral standard and that pervades the common person. Unfortunately, from a lot of these videos many people will be disgusted and offended by what they see. How will this facilitate tolerance? Simply opening the floodgates won’t ensure that viewers will react well. Additionally, this perspective also assumes that videos will be more or less unbiased and all-encompassing. The media and government aren’t the only ones who will purport to know the truth. In fact, my guess is that the Pangea Day committee themselves will probably have to censor some of the videos.
But, all in all, I find this to be a valuable endeavor. It was put together well and, if it gets enough press, should promise to bring a lot of interesting videos to the global fore. What happens as a result still remains to be seen…
September 14, 2007 1 Comment
It doesn’t take much for me to get inspired about design but it’s rare that I can find nothing critical to say. I had the opportunity to see Cameron Sinclair speak about Architecture for Humanity today. It was a fantastic presentation given by an amazing architect doing incredible things. If you’re familiar with Habitat for Humanity, you can probably guess what his group does. This group creates architectural designs for under-served areas such as the Gulf Coast after Katrina, Sub-Saharan Africa, and areas hit by the tsunami of ’04.
The talk was obviously inspiring for the work that was being done. But what I was most impressed with was the reflection upon their own design process and how it unfolds in this context. At one point he put up a slide just showing the principles they have taken away from these experiences and I found a lot of intersection with my own thoughts on HCI in the developing world. The group’s reflections seemed well-founded with an underlying concern for culture and geography. All too often it seems that designers in any field are looking for the panacea. This group “gets it”.
I found no room for criticism because this this group is practicing what they preach. They have had tremendous success in a lot of their projects. They have done so in many locales with varying cultures. There design solutions are all unique. Additionally, there is a strong emphasis on participatory involvement on the part of those that will live in these dwellings. They have realized that success will always rely on the stake that users will have in the solutions (he also mentioned that they do not allow sponsor’s names to be written anywhere on the structures they help fund).
Finally, the most interesting portion of his discussion was his emphasis on learning from the group’s failures. He didn’t spend much time dwelling on the point but it was an important one nonetheless. On the website for his current project: the Open Architecture Network the group has even listed failures (he showed this in the presentation but haven’t found it yet online). Everyone preaches that mistakes teach more than successes but this is an example of a group that actually practices it. It is, no doubt, hard to admit failure, but in the end we can all benefit from this humility as design community.
September 7, 2007 No Comments
Small Things Considered
by Henry Petroski
A very light and fun design book for designers in just about any discipline. The historical accounts he gives of the smallest objects such as the the paper cup to the grocery bag illuminates the beauty of design.
I usually read “deeper” design books but this is a refreshing read because it concentrates on design in its simplest form–away from the digital and mechanical. Every chapter essentially tells a story of the evolution of different products. Though, I did disagree with some of his assessments of “what” design is. For instance, one chapter he explains the act of eating out with a group at a restaurant as being a design choice. I disagree as this has more to do with simple decision-making more appropriately described by anthropology, sociology and psychology. This particular chapter I felt could have been omitted altogether.
Aside from that, every chapter stands alone as a thorough account of how design pervades everything. It will be illuminating for non-designers because it exposes the constraints and compromises that are involved in the design process. For designers, it should prove to be entertaining if not a little humorous as Petroski makes it easy to empathize with these accounts. A very entertaining read for those in the field or those who are simply intrigued by what goes into everyday products.
June 14, 2007 No Comments
As I research methods and theories of HCI for my capstone project I often come across authors discussing how the multi-disciplinary qualities of HCI affect an academic vocabulary. Our field is relatively new and is evolving at a rapid pace. It essentially started with borrowing theoretical frameworks from cognitive psychology but now has expanded from what seems to be everything from anthropology to sustainability (although, this is not truly an academic discipline…you get my point). What gets lost with this evolution is a well-defined vocabulary and more important to me personally, what HCI/d really is.
Often I come across papers that discuss HCI/d in terms of usability testing and maybe includes empirical evaluation of designs in terms of mouse clicks or modeled using GOMS. However, I view design more about the creation of something yet to be and engineering concerning modifying and improving the created. I don’t mean to say that engineering is not a component of design–a valuable one at that. Rather, I think the field of HCI needs to begin making a distinction between the two because I find the implications of both frequently getting muddled in design discourse.
Partly, this point-of-view is highly influenced by two of my mentors Marty Siegel and Erik Stolterman (particularly in his book Thoughtful Interaction Design), but it also reflects my experience as a design mentor in the graduate introductory design discourse. I often found students new to the field attempting to construct usability tests to discern whether a design is good. I had to point out that these methods are not suited for this but rather for honing and evaluating the effectiveness of a given design.
While there are many other methods beyond just usability testing, I use this as an example of what I have come to see as a distinction between HCI Engineering (HCI/e) and HCI Design (HCI/d). As the field of HCI continues to grow and evolve, I believe creating a typology of sub-disciplines will make the field more effective in the future.
March 23, 2007 4 Comments