Category — design

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?

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.

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:

1. 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.
2. 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”.
3. 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:

1. 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.
2. 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.
3. 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.
4. 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.

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.

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.

For my graduate capstone I am researching the role and appropriation of interaction design in rural areas of developing countries. As I research a lot of information and communication technology (ICT) projects or UNESCO-sponsored initiatives, I come across a lot of implications for what to do in the future. Most of these projects are failures but even the successes often cite this one implication: “The technology utilized should be affordable.” What the hell does that mean? Why would anyone consciously develop a technology that is unaffordable–especially in the cases of poverty-stricken rural areas. This doesn’t make any sense. To think that these ICT projects might fail because the creators did not consider cost, or that the major insights are to simply make the technology affordable in the future, is ridiculous. Why isn’t that common knowledge? Apple wouldn’t make an iPod that costs $2,000 aimed at college students so why would a developer implement a technology that costs thousands a year in maintenance in a village that has an average income of a few hundred dollars a year? I mean, Sony wouldn’t sell a Playstation 3 for…..okay, wait, that might not be the best example

So what I really wonder here is what is at the core of this ‘design implication’? In this setting I think what is really at play is that developers do not design the system/artifact in a way that makes the user capable of maintaining or improving upon it in the future. If the system relies on outside support it is doomed to fail because researchers and developer can only linger so long to ensure a project’s success. I read all too frequently that projects might be a raving success while the developers are still around, only to find that years later it becomes a dismal failure. The failure is actually amplified by the fact that when users become accustomed to a system/artifact, they change their activities to center around it. As a result, when it leaves, they are left in a worse condition than before. So my thoughts on this idea of “unaffordable technology” are that designs in these settings must be participatory and adaptive. Developers and support cannot be around forever so it is important that the designs can not only be learned by the users but mastered in such a way that the user then becomes the designer (see Acting with Technology by Nardi and Kaptelinin for more on this). This way, Users can take ownership and innovate for their own uses. From a participatory standpoint, designs can most likely become adaptive. In this sense, the design is possibly modular or it is malleable so that it can be modified and reappropriated in the future. If implementations have adaptive capacity then their usage will be more sustainable.