Last weekend, I helped to organize and host the first annual SketchCamp. SketchCamp was a one-day event for interaction design and user experience (UX) professionals; we ran it like a BarCamp with a focus on UX sketching. It was a total success!

Since then, several people have reached out to get more info on SketchCamp so that they can run one in their city (Vancouver, Chicago, DC…) That’s really exciting, and I want to support that as much as possible. Thus, I’m starting with a blog post to give some background — and anyone who is interested in talking more should email me directly. (Be sure to check out Behind the Scenes below)

How SketchCamp came to be
Greg Nudelman and I were inspired to produce SketchCamp in SF after attending a similar event, DrawCamp, in Milwaukee last year. We came back from DrawCamp with new tips for drawing and sketching, taking sketchnotes, drawing upside down, writing while talking, etc. etc. We felt that the appropriate focus in the Bay Area would be UX sketching. Hence, SketchCamp was born!

Eight months later, we were a crew of 4 organizers (Greg, me, Josh Williams and Netta Marshall), 4 volunteers (Kathryn Storm, Scott Tran, Liz Dalay, and Jessica Skelton), myriad sponsors (Jess3, DesignCaffeine, HotStudio, UIE, Autodesk, Rosenfeld, and Square), and were lucky to have a beautiful venue (Singly Headquarters) for our Memorial Day weekend event.

Day of the event
The day before the event, all the organizers and volunteers gathered at Singly to breakdown their office equipment (tables & chairs) and set up for SketchCamp (our chairs, our layout). This took about 4.5 hours to do with 7 people helping. We set up and prepped for everything except for placing signs on the walls and blowing up balloons, which we saved for the next morning.

On the day-of, we arrived at SketchCamp around 7am for final preparations. Breakfast arrived around 8:15…our speakers showed up early to set up…and the first attendees rolled in around 8:45am. By 9:30, we kicked it off!

The rest of the morning, we had 3 speakers presenting on sketching and UX-related topics. Jared Spool spent 45 minutes in a conversation with the audience about how to get non-sketchers to be more comfortable sketching. Dan Willis then shared an interesting perspective on how to think more holistically about UX design by focusing on “intent paths”. Finally, Dana Chisnell led us in a 1.5 hour design studio workshop on redesigning the ballot. Kate Rutter did awesome graphic recordings of the first two sessions.

We took just over an hour for lunch, and people split off into clusters to chat with each other all over venue. At 2pm, we started the BarCamp portion of the event. We had 3 breakout rooms (named after famous UX sketchers), and each session was 25 minutes (allowing 5 minutes for people to move to the next session). Two rooms had white boards; one had a projector and a easel with large post-its.

And, of course, the sessions all went really well:

Daria Kempka (organizer of the original DrawCamp, Milwaukee) took this great set of photos:

And one of our volunteers, Kathryn Storm, shared these photos:

Behind the scenes

Leading up to the event
In the months leading up to the event, the organizers met 1-2 times per month until about 8 weeks out, when we started meeting weekly. Our weekly meeting spot was The Grove Cafe (Mission @3rd St.) — it was open late, had wifi, and served pretty tasty food and wine & beer. It was also conveniently near many of our downtown offices. After we signed on a few volunteers, they also attended our weekly meetings to get up to speed on our planning and help out in whatever ways they could.

Our weekly meetings involved reviewing what progress we had made in the previous week, adding and removing items from our to-do list, and divvying up responsibilities. These meetings were working meetings since we had very little time outside of Tuesdays from 7-10pm to devote to planning. This model worked pretty well for us, though, since we gave ourselves enough prep time between announcing the event and actually putting on the event.

In fact, we originally planned to have SketchCamp back in October or November 2010. We kept finding conflicts with other events and with our own schedules, so after we got sketchcamp.com set up, we picked a date in the distant future when we were all available. That date was May 28, 2011, and at the time, none of us realized that it was Memorial Day weekend! (This didn’t prove to be much of a problem, though. It deterred a few people from signing up, but there were plenty of other people to take their places.)

When we finally announced SketchCamp on January 5, 2011 (early bird tickets were $20), we sold out in 2 days! At the time, we were planning to have the event at ModCloth where our max capacity was around 75 people, so we released only 60 early bird tickets. It was only later when we switched venues from ModCloth to Singly that our capacity increased to 100, and we released another 20 “regular admission” tickets for $40 each. That second round of tickets also sold out in a day.

We were not expecting SketchCamp to be so popular or to sell out so quickly! There is definitely interest in the UX community for an event like this (and I’m sure there will be in other cities too!) We joked about how we should have put a higher price tag on the event…and we could have used more funds (we came in over-budget by about $200). If we had had to pay for our venue, we would have been out an additional $500

And yet historically BarCamps have been free, so we were hesitant to charge even $20 for attendance at first. However, we knew that we needed to provide breakfast, lunch, and random other supplies, and we didn’t have sponsors lined up back in January who would cover our costs. $20 is a funny number — it was nearly enough to cover food and drinks for everyone, but not enough to deter people from randomly signing up and then bailing on the day-of. We had about 25% attrition and, thus, had about 25% more food than we needed. I guess it never works out perfectly….

The next time around, we will think about charging $50 or even $75 per person, especially if the event remains as a single-track of speakers in the morning and a BarCamp in the afternoon (aka not a 100% pure BarCamp model). As I mentioned, we would have needed the additional funds if we had had to pay for our venue…

Our budget
We ended up with a budget of about $3450, through a combination of sponsorships ($1250 total) and attendance fees ($2200). Our total costs exceeded this amount by about $200 — which isn’t that bad in the big scheme of things, and which the 4 organizers settled by splitting up the remaning costs amongst ourselves.

Our main costs were:

• Food = $2650
• Supplies = $300
• AV equipment and chair rentals = $585
• Domain hosting/setup costs = $135

We were lucky to have our venue donated to us by Singly, but several other venues we were considering cost $500-$1500 for the day. Those options would have totally broken our budget and would have been less ideal all around. We ended up with a spacious, comfortable, and gorgeous live/work space in the Mission with tons of light. It made for a cheery atmosphere and cheerful attendees!

Our food was the most expensive item in our budget at $2650. This included breakfast, lunch, and 2 coffee services from Radius SF. When our total headcount was only 75, their food quote came to ~$24 per person. When we went up to 100, the quote increased to $26.50 per person. Both quotes seem to be pretty reasonable, especially because Radius makes totally fresh and home-made organic food (all sourced from within a 100 mile radius of SF).

We could have reduced our budget slightly if we hadn’t needed to rent AV equipment. That rental alone was about $480; chairs were only about $1/chair.

Krista’s photos:

My photos:

It’s exciting that South by Southwest is just around the corner! When I submitted my panel proposal back in, what, June? July?…I had an inkling that games would be an interesting topic, and I was particularly interested in social change. Hence a panel proposal which is now called: 1UP! Games for Change. (hashtag will be #1UP)!

Yesterday, James Renovitch published an article in the Austin Chronicle based on an interview with me, Thor Muller, and Dave Gray about our respective game panels: “Gaming the System: Applying the mechanics of play to the everyday“. It got me even more excited about picking the brains of my two awesome panelists, Zao Yang (of MyMiniLife/Farmville) and Jude Ower (of theplaymob.com), about their perspective on “gamification” and how games can be used to motivate people to change their behavior – for personal or social change.

The short version of the panel is this:

This panel will explore ways that games can be used to motivate personal change and increase productivity. We’ll start by talking about the theory behind games and gamification for behavior change — in contrast to games for social networking (e.g., Foursquare) — and how game-like activities have been used for a long time to encourage people to change their own behavior. Then the discussion will revolve around applications of game theory in practical, everyday situations (e.g., in the workplace, for dieting, parenting, reducing our carbon footprint, etc). Our panelists will talk about their experience in these situations — what games they chose, how the games helped change people’s behavior, and any take-aways they have for using games in your own life or building them into your next enterprise.

For the long version, come attend the panel in Austin!

1UP! Games for Change: Tuesday March 15, at 5:00pm in Room 6AB of the Austin Convention Center.

The premise behind it is that we (designers) can apply our skills to actual, real-world social problems like unemployment, urban violence, public education, community mental health, and cross-cultural understanding. User experience and visual designers are known for being creative problem solvers, but their skills have not been traditionally valued very highly in organizations — or in the non-profit world. Mashable wrote a summary of the event and why designers, specifically, were picked to help come up with solutions to hard social problems.

Pretty rad, I think. And I am honored and stoked to be participating in it. Here’s why:

First, it’s important from a civic-duty perspective for us all to participate and “give back” to the community in our own ways. I don’t do much volunteering anymore, but I have in the past and it’s always been very rewarding. And today, one way I can give back is through design.

Second, I’ve been to iPhone Dev Camp and other hackathons as a “guest” — not as a participant — since I’m not a developer. It always looked like a lot of fun to work with a small group for a day or two, build something, and compete against each other on a project. But there haven’t been any “hacking” competitions for designers (that I’ve known of). UX for Good is specifically a designer hackathon — which is just about the most exciting thing I could imagine right now!

(Side note: I’ve been organizing a hybrid design/hacking competition in San Francisco recently, because I’m passionate about getting designers and developers to talk and work more together! The focus also had a civic-duty angle: to help prepare people in times of natural disasters/emergency response. Unfortunately, I had to resign from the organizing committee because organizing 3 conferences at the same time while working at a startup is crazy business. I believe the event is still being planned, so if you’re interested….stay tuned!)

Third, the UXXU attendees are some rockstar designers that I’m very honored to be working with! I’m hoping that this weekend lets me learn and grow in ways that I can’t (or don’t) during the week at work.

Fourth, it’s based in Chicago! Chicago is an awesome town and, importantly, it’s not San Francisco! I believe the dedicated technorati of SF need to branch out from the Valley and learn from practitioners elsewhere. This seemed like a perfect occasion for that very thing, even more so than an Interaction’11 or IA Summit (both of which I’m bummed to be missing!).

In addition to being an awesome design event, it happens to be the same weekend as ORD Camp — a barcamp inspired event that’s put on by a few folks from Google, and happens to be invite-only, but brings together the top tech thinkers and do-ers in Chicago. Chris and I attended last year (as the token out-of-towners) and we were both planning to attend this year as well! When UX for Good came across my radar, I realized that it’d be a better event in terms of professional growth — but we were still able to travel and stay with each other in Chicago over the same weekend! Bonus!

Our topic dealt with privacy issues in 2019 when we may, theoretically, have some device hanging behind our ears — or someplace discrete — that reads our thoughts and interfaces with things in the world. Other people could become aware of our thoughts and feelings (although the specific mechanisms of how this would work were left up to the imagination).

Instead, we wanted teams to think up a context and situation where privacy issues would occur and how people in that situation would deal with it. Here is what each of our three groups came up with:

Team #1: “The Street Tigers” — related to privacy while crossing a street:

Bodystorming privacy Group #1 from Brynn Evans on Vimeo.

Team #2: “The Retail Tigers” — related to privacy while shopping online:

Bodystorming privacy Group #2 from Brynn Evans on Vimeo.

Team #2: “The Sick Tiger Puppies” — related to privacy issues in a doctor’s office:

Bodystorming privacy Group #3 from Brynn Evans on Vimeo.

Is design thinking really that hard? There is obviously a growing acceptance of the notion behind design thinking as the previous essays and comments pointed out. But it remains that there is no formula for design thinking, and because of that, design thinking may alienate business leaders, managers, or even UX practitioners.

Consider the following quotes:

• “Design thinking is not about solving design problems, it’s about solving problems with design.” –Paula Thornton
• “It’s not just thinking. It’s a structured approach to organizing design.” –Gayle Curtis
• “Good design is at the intersection of business and human goals. It’s not just about users, and it’s not just about business—it’s about balancing both.” –Jess McMullin

A natural reaction to this is: Great! Sign me up! P.S. I have no idea where to begin.

Even as the essays on this panel have hit the nail on the head in how design thinking can be used for innovation in businesses, it still feels like an elusive process that faces many barriers in actual organizations. I’ve been noticing this with one of my clients. After introducing some new user-centered, user-driven design, marketing and sales invariably rework it to echo their time-tested sales pitch, causing it to bloat with extraneous options, text, and check boxes. In the end, we’ve made only an incremental improvement in our design.

Yet, I’ve also noticed a theme emerge across the many articles on design thinking recently. Bruce MacGregor talks about the importance of gaining insights early. Venessa Miemis mentions Tim Brown’s book which outlines an “inspiration phase” (disclosure: I have not read the book myself). And Peter Merholz continually reminds us that users are the central to the design process.

At the same time, I saw this surprising graphic last week: that “science” only makes up a sliver of the design thinking process. Really, I thought? What about the aforementioned importance of understanding users—isn’t that like a “science”? Maybe this is partly explains the uncertainty and confusion around design thinking.

[via http://www.kaplusa.com/blog/2009/12/the-role-of-intuition-in-design/ ]

I prefer the way that David Gillis describes the tradeoff between science and art as more of a continuum. Even still, where does design thinking fit in? A notch closer to the art, or to the science?

[via http://www.teehanlax.com/blog/2010/01/20/the-art-science-of-evidence-based-design/ ]

Taken together, I wanted to write a piece on the “science” in the design thinking process, to reiterate the importance of user-centered design and try to illustrate how this is not just a black box. Hopefully there’s some stuff in here that will help companies grasp exactly what we mean when we talk about “innovation” and “design thinking.”

One way to think of the innovation process is as a funneling of ideas across various stages—stages that span needs-finding, synthesis, ideation, prototyping, and iterating. Of course, this is a cyclical and dynamic process so it’s somewhat misleading to represent it as a sequential progression.

[via http://www.slideshare.net/mikeyk/intro-to-design-thinking ]

Gillis represents this process slightly differently, but still captures the same basic design phases:

[via http://www.teehanlax.com/blog/2010/01/20/the-art-science-of-evidence-based-design/ ]

Now, I prefer to think in terms of craft and creativity rather than science and art. By craft, I’m referring to the well-defined and established process of user-centered design. Creativity is the art, shiny design-y, intuitive part—the window dressing if you will. And to an extent, all these phases can be said to involve both craft and creativity.

It’s the craft part of design thinking that I want to elaborate on in the rest of this post, since the craft can be taught to a greater extent than the intuitive, experiential, creative part. Afterall, there are books and workshops out there teaching contextual and user-centered design. One great resource is IDEO’s Human Centered Design Toolkit.

Investigate / Observe:

Remember that the point of user-centered design is to gain clues about unmet user needs—needs that users themselves may be unable to articulate. The only way to gain this insight is to embed yourself in the community and practice of the people you’re designing for.

To do this, you must first scope your project and define various goals and hypotheses (what IDEO calls a brief).

Next, you talk to end users directly to learn about how they think, act, and engage, either with your product or in the space where you want to design a new product. This involves conducting contextual interviews, field studies, or otherwise observing users in their natural environments (not in the lab). If you’re designing an e-commerce checkout application, watch a user’s entire purchasing process from start to finish. If you’re redesigning your own site’s checkout flow, watch your users’ purchasing process. This is not a usability study. You’re not looking for feedback on specific features of your checkout process; you’re looking holistically at what your users’ goals are, what they’re doing to address those goals, where breakdowns occur, where confusion arises because expectations were violated, and importantly, how they feel (emotions! emotions! emotions!)

Synthesize:

There are number of established ways for documenting and synthesizing your insights. For example, interpretation sessions should be run as soon as possible after gathering user data, and they should always be done with other people—both people who were at your observation sessions as well as people who weren’t. Although it sounds counterintuitive, people who weren’t “in the field” with you often see the problem space from a different perspective, which causes important questions to be raised that might otherwise have been overlooked.

Some of the methods to use in interpretation sessions include building affinity diagrams, modeling workflow and cultural influences, and generating personas. Not all of these activities will be performed in the first interpretation session, but they are all part of the craft of synthesis in the design thinking process.

What you should be left with after this is a set of design principles in which you can begin to think about how to innovate on your product.

Ideate / Brainstorm:

Ideation and brainstorming is as critical to design thinking as is the collection of user data. After you’ve gathered your design principles, the goal is to generate ideas about how to create a product, service, or experience based on those principles. Gayle Curtis has an excellent talk on how to run such brainstorming sessions. Again, it’s a craft to structure the session— although what it generates is intended to be very creative, exploratory, and experiential. The more ideas the better.

Another excellent way to ideate is through what Dennis Schleicher calls a Issue Board. Issue Boards are, in fact, quite structured while still being visually evocative. They are generally built by one or two individuals, but subsequently used in larger brainstorming sessions to generate ideas.

Prototype / Evaluate / Validate:

I’m specifically lumping the prototyping and evaluative phases of design thinking together, to emphasize the point that prototypes are intended to solicit feedback. Yes, prototyping is an activity that can involve lots of creativity and visual aesthetics. But prototypes are not simply a beautifully-packaged, first generation version of your product—prototypes come in all shapes and sizes (from conceptual mockups to paper prototypes to high-fidelity interactive products).

In order to use prototypes to generate feedback, you must be open to testing your ideas early and often. Explore some conceptual mockups, and get feedback from a few users; then move onto paper prototypes and get quick feedback again; etc. This can also involve something like participatory design, whereby users are directly involved in the development of your prototype. There’s a good example of this in the Design Thinking for Social Innovation article: IDEO worked with children directly to develop a comprehensive vision care system for VisionSpring (the local provider).

…

As most will agree, design thinking is no panacea, even when combined with business thinking. Perhaps organizations become fearful of its outcome; or the numerous stakeholders and deep-seated traditions make it difficult to use design thinking in practice. One way to deal with this problem is to create an emotional connection with business leaders and UX professionals, in much the way we want to create an emotional connection with our users.

To do this, we must continue sharing examples of design thinking across a range of problem areas (which I have not succeeded in doing, but which unstructure has placed a call for). Sooner or later there will be a compelling example that resonates with every industry! We must also providing the necessary resources for others to embark on the design thinking process themselves. The goal for this essay was to do just that: illustrate how to put the craft in design thinking.

Our Abstract: In this session we will talk about design thinking and how it relates to software product development in general, and to HCI design in particular. We will also explore the values and methods of strategic ideation and see how they can be applied in various real life/real work situations.

Working in a product development environment we often find ourselves grappling with tricky, squirrelly problems. Requirements are often vaguely defined and frequently change as new information emerges about the market, our competitors, etc. How do we design for the right solution when objectives are unclear and requirements are shifting? Moreover, how do we get all the stakeholders to agree on the same outcomes?

A traditional business approach might dictate the use of logic and a clearly defined process such as a SWOT analysis to build parity, while a design thinking approach might consider the end user’s goals and seek out an innovative solution that aptly fulfills their needs. This presentation will show that the two solutions become more effective when combined, and offer an optimal solution that adheres to both user and business requirements.

Overlap SF from Brynn Evans on Vimeo.

This is what we do: we have fun, we create stuff, and we live by the cardinal rule of DON’T OVER THINK IT!!

Come join us!
groups.google.com/group/overlapsf

A word before I go on: I generally think it’s dangerous to assume a searcher’s intent based on their search query terms alone. A premise in Click is that at scale, we can pull out things like intentions and motivations from web-wide trends. While Tancer could make a stronger statement about being cautious around intent (he does this in a very subtle way), he also illustrates how huge sets of internet search data do reveal things about us that we may not offer up willingly (if asked about it).

He makes this point about porn and also about fears. Expanding on this notion, I want to further illustrate how what we say is not necessarily what we do.

Tancer notes that the results from a nation-wide survey asking people about their phobias was substantially different from the list of fears he uncovered in his web-wide search query data. The survey, callled the National Comorbidity Survey, found that people’s top nine fears were:

1. Bugs, mice, snakes, and bats
2. Heights
3. Water
4. Public Transportation
5. Storms
6. Closed spaces
7. Tunnels and bridges
8. Crowds
9. Speaking in public

In contrast, the top ten fears from queries containing “fear of” (after filtering for non-phobia fears) were:

1. Flying
2. Heights
3. Clowns
4. Intimacy
5. Death
6. Rejection
7. People
8. Snakes
9. Success
10. Driving

What’s interestingly different from these two sets is that the non-survey results (2nd list) includes more social fears: “fear of intimacy,” “fear of rejection,” “fear of people,” and “fear of success.” Why might these differences be present? Perhaps because people don’t want to admit their social phobias to the person administering the survey? Perhaps because, when asked about a “phobia,” people will think of things (heights, water, tunnels, snakes) and rather than social scenarios.

Either way, what people say and what people do (think or mean) can be seriously different; and this is the greatest danger of relying (exclusively) on survey data.

This is always at the forefront of my mind as I’ve designed, administered, and analyzed many types of surveys. However, surveys can be well-positioned in the research and design process provided a few tips and guidelines are observed:

1) Avoid asking for generalizations!
People are terrible at estimating how long, how much, or how often they do something. There are some exceptions to this: if you truly do something everyday (like shower first thing in the morning), then you’ll be better at discussing your behaviors (in the abstract). Infrequent behaviors are hard to estimate and should generally be avoided in surveys.

But Brynn, you might ask, you just ran a survey asking people about their coffee drinking behaviors. Is this reliable data? That’s an excellent question, but you have to also take into consideration our intended use of that data for the betacup project. We intentionally planned to collect data from a few hundred people to identify apparent use cases and patterns, which we will subsequently investigate more directly through interviews and observations in coffee shops. Therefore, my second tip is:

2) Surveys are well-suited for establishing basic trends and underlying patterns.
I would not design a product or service around survey data alone! They can be suitable as the first step in a research program, but don’t confuse the power of numbers with the power of direct observations. Having 250 or 1000 data points in a survey provides a completely different perspective on a problem than watching 5 people move through, order from, and drink coffee in a coffee shop, for example.

However, I have learned that if you get people to talk concretely about a specific time in their past, they do a reasonable job recounting it.

3) Getting people to talk in specifics will improve the reliability of survey data.
I’ve been using a modified critical incident reporting model for collecting information from people online. Typically critical incident reporting was a technique used in face-to-face interviews: A researcher would ask a user to describe a time when something specific happened (a salient episode from the past). These are called “critical incidents” — but I’ve found that this general method can be applied to everyday episodes if you ask people to describe the last time something happened. For example, can you tell me about the last time you read a book or cooked dinner at home?

One caveat on this approach: actions that people take very frequently or very infrequently are harder to recall. Do you remember the last time you hand-washed your car? (This is presumably an infrequent behavior). Or the exact steps you took to get prepared for work this morning? (This is may be done on auto-pilot if you have a regular routine.)

If you have other tips or guidelines for studying user behaviors from written, remote surveys, please share them here!

In the modern digital age, online surveys are cheap and quick to administer. Yet they are not trivial to design and caution should be taken to make sure every question serves a purpose relative to your overall project goals. As designers we must be cautious about the reliability and generalizability of survey data alone. What people self-report (I have a fear of bugs and mice) may be very different from what people actually mean (I have a fear of people, intimacy, and rejection). Yikes.

“I grabbed a cup of instant from the hospitality table on the second morning of orientation. It was piping hot and I was in a hurry, so I stuck an ice cube in, but then a friend hailed me and began chatting; by the time we parted, I was holding a cup of watery lukewarm coffee.” –Anonymous (F, 18-24 year-old student from Virginia)

As we learn more about coffee drinking behaviors — the practices around buying and consuming coffee — the better we can tailor the design of a so-called “betacup.”

Krista Sanders, an original member of our team from Overlap’09, has the following reflections on user-centered design and our approach to coming up with a practical solution to the “paper cup problem”:

1. Behavior influences design. Identifying current behavioral patterns provides a solid launch point from which we can design improvements to the existing workflow or process.
2. Relevance increases adoption. By understanding a user’s basic tasks and goals, we are more likely to create potential solutions that not only adhere to, but also enhance the overall experience.
3. The Convenience Monster MUST be appeased. Centering the design process around even the simplest of user expectations is one of the most important requirements for achieving a successful design.