Should designers be able to code? 3 cognitive biases that influence your answer.

It’s a played-out out question that every interaction designer has heard, and likely argued about, many times in her career; should interaction designers be able to build what they design? When formulating your opinion, or reading the opinions of other designers, consider how these 3 cognitive biases may subtly influence our answers:

1. Designers who code overvalue that skillset (ownership bias).

People overvalue what they own, and a designer who is able to code is likely to overvalue how important her coding skill set is to design.

2. Designers who can’t code avoid cognitive dissonance by believing that coding is unimportant (belief consistency).

People avoid cognitive dissonance, the discomfort from holding 2 or more conflicting view points at once. A designer who believes she is good at her craft but cannot code is unlikely to believe that coding is important for designers as this would cause cognitive dissonance.

3. Designers over-estimate and under-estimate the value of coding in these discussions because it is the focus of the discussion (attention bias).

Because people have limited attention and memory they overestimate the importance of the subject at hand. If coding was brought up in the context of a dozen other important design skills, designers on both sides would likely have more moderate answers.

 

Delighted by Gmail

Gmail reminding me to attach a file.

I was pleasantly surprised when Gmail parsed the text of my email to figure out that I forgot to add the attachment I intended to send. This is an example of really thoughtful design.

 

Celebrate & Reward Future Achievements

Image of a poster that celebrates a future achievement.

What if you celebrated a big future achievement before you even started working on the project? Imagine that your team threw a party, gave out bonuses, and hung up posters celebrating the fact that you are going to hit a big goal in the next year. If the goal is not hit, the posters will come down and the bonuses will be returned.

A recent study on loss aversion found that giving teachers a performance bonus before the year starts, that would be taken back if goals were not hit, improved teacher performance significantly. This study was focused on financial incentives, but I am curious if the party and poster would be effective in their own right. Is there a feeling of loss when taking down a public poster that celebrates an achievement? Does a party that celebrates the achievement of a future goal increase the team’s commitment because they feel like they need to reciprocate?

 

Are you going to get an interview for that UX job?

You applied for a UX job at your favorite tech company and are waiting to hear back. If they liked what you sent them, they will set up an interview and you are one step closer to your dream job. If they didn’t like it, well, we all know how that one goes. This flow chart will help you better understand whether or not you are going to get called back in for an interview.

A chart about the chance of you getting an interview for that UX job you applied for.

 

Involving Developers In The Design Process (9 Tips)

Note: This post is a follow-up to 3 Reason To Involve Developers In The Design Process.

1. Invite developers to take part in ideation sessions.

Many design ideas.When working on a new feature or product it is pretty standard to run ideation sessions where a group of designers and product managers rapidly sketch and explore ideas. By inviting developers on your team to join in these sessions you get the benefit of hearing great ideas from people with a different perspective. Developers appreciate being invited to these sessions as they often have ideas about the product and these sessions give them an opportunity to express those ideas and have a hand in shaping the product.

2.Keep the ideation sessions short, efficient, & fun.

You should be running short, efficient, fun sessions anyway, but it is especially important when involving people who are taking time out of their normal job to participate. Send out an email before to explain the context and design goals, use the first couple minutes of the session to review and clarify the goals, and then get right in to the sketching. If the session feels boring or like a poor use of time, there is a good chance that your development team will skip the next one.

3. Run 10-minute design reviews with your scrum team.

The review should cover a design you plan on building in the next couple sprints. Quickly walk the developers through the design and send them a link to the design afterwards. These reviews are short enough that they can be tacked on the end of standup, when the team is already together. This review should be separate from design reviews with PMs and designers as those usually take much longer and can often spiral in to other product design discussions.

The benefit of these reviews is that you get more eyes on your design and some guidance around how hard things are to build. Developers appreciate these sessions as it gives them a forum to voice design concerns and because it gives them a preview of what they are going to be building in the next couple sprints.

4. When you invite developers, make them optional.

Being involved in the design process should feel like a fun opportunity, not more meeting overhead. For both the ideation sessions and the design reviews make all of the developers optional. It will quickly become obvious which developers love getting involved in the design process and which have no interest.

5. Design-loving developers make great informal design collaborators.

The developers on your team that love being involved in the design process can be great partners to bounce ideas offDesigner & developer working through problem at the whiteboard., work through problems with, and get quick, informal feedback from. A great side effect of this collaboration is that by being more involved in the design process these developers will become more bought in to the design and will put in the extra hours to make sure the design gets built.

6. Only involve developers in products they will build soon.

It is less important to involve developers when the design is more forward looking, like a design vision or a sales prototype. The main purpose of these artifacts is to communicate and align people around a high-level approach. If the forward-looking design is well received you will end up going through the design process with more rigor, using the design vision as a rough requirements document. This second time through the design process you determine what will actually get built and this is a more useful time to involve developers.

7. When the design is well received, spread around the love.

When you receive praise at at a meeting for a design, mention that most of the great ideas and direction came from others and call out individuals when you can. This acknowledgment and positive feedback builds good will on the team and increases the likelihood that developers will participate in the design process.

8. If shit goes wrong, take responsibility.

Occasionally a design will fail to hit certain goals and it will be subject to internal criticism. No matter who originally came up with the idea that is getting dumped on, you should take responsibility for the failure. You harvest ideas and feedback from others, but at the end of the day it’s your job to sift through the ideas and feedback to deliver a great design. Blaming the failure on anyone else is a sure way to lose goodwill and ruin any chance of developer involvement in the future.

9. Be appreciative.

People are taking time out of their busy lives to help you design a better product. Thank them.

 

3 Reasons To Involve Developers In The Design Process

The goal of an interaction designer is to get the best possible product in the hands of users. Almost everything we do, from research to documentation, is in an effort to reach this goal and I believe that involving developers in the design process is paramount to delivering a great product. Here is why:

1. Developers have great ideas.

It’s foolish, and a bit condescending, to think that someone won’t have great product design ideas just because their title doesn’t have the word ‘design’ or ‘product’ in it. Developers spend countless hours building and using tech products (often in the domain you are working in) and they bring tons of great ideas and feedback to the table.

2. Understand development tradeoffs earlier.

As the design goes through reviews and iterations it’s great to have developers involved to both critique the design and to keep you informed about features or UI elements that would require large amounts of development time (as well as ones that come cheaply). Since most projects have limited development resources, understanding development costs early allows you to steer the design in a direction that gets the most value for your development buck.

3. Buy-in & belief means more commitment to build out the full design.

If a development team believes in a design and feels ownership of it they are much more likely to the make the full design a reality, even if that means long days and extra hours. We have all worked on projects where the development team simply ran out of time and had to cut scope, leaving some great delighters out of the product. I have found that this happens less frequently when a team is truly bought-in to a design.

Development team output increases if they feel more ownership of the design.

There are a number of reasons why involving the developers in the design process is a great way to get this (very important) design buy-in from them. Here are a couple:

  • No one likes being told what to do and by involving the developers in the design process it makes it feel more like a team effort and less like a designer telling them what to build.
  • People are more likely to support a design they helped shape, and when you involve developers in the design process the final output is truly a result of their ideas and feedback. It’s important to highlight these contributions so when I present a design I always credit members of the team who contributed ideas that affected the design and those who gave feedback that lead the design in new directions.
  • No one wants to build something they think is shitty. Having the developers in design reviews allows them to voice their concerns which allows you to either adjust the design accordingly or to explain the rationale for the current approach.
  • People are more likely get excited about a design that solves an important problem, and involving developers in the early design explorations, where context and goals are presented, gives them a better sense of what we are solving and why.
  • People are more likely to support a design that has had a lot of hard work put in to it. Your end deliverable looks similar (on the surface) whether you spent 5 or 50 hours on it but when involved in the design process, developers get to see the various steps and the amount of thought put in to a design.

Convinced that developers should be involved in the design process?

Yes? Awesome. The next big question is how to involve developers so that you get the most value out of them, they feel involved, and you don’t use up too much of their time (someone has to actually build the product). I will cover these topics in a follow up post, as well as related topics like which projects should involve developers (hint: not every project) and which developers on the team to involve.

Update: Here is the follow up post about how to involve developers in the design proces.

 

Overview of Gamification Summit 2012

I attended GSummit a couple of weeks ago and wanted to share some of my takeaways.  The conference itself was very well run (hurrah for short sessions!) and I have summarized the more thought provoking talks below:

4 keys to fun: Nicole Lizzaro gave a great, example-laden talk about what makes things fun.   This chart on her website provides a great framework to use when thinking about making something fun.

Freshness, community, & cooperation:  Dan Porter gave a humorous talk about the success of Draw Something and brought to light some interesting insights around the importance of app freshness, community engagement through being human, and the underutilization of cooperation in games.

Different players, different motivations:  Richard Bartle talked about the 4 categories of player motivation (achievers, explorers, socializers, killers) in massive multiplayer games and how although these may not apply to your software it is important to remember people are motivated by different things.  Although there is not much new here it was a good reminder to avoid the trap of focusing on a single user motivation.

Engagement layer: Keven Akeroyd of Badgeville gave a high-level talk about where he saw the industry going and the one point that resonated with me was the idea that all new features should have an engagement layer on it.   As usability becomes table stakes in consumer software, this engagement becomes the new competitive advantage.

Small achievable goals and levaraging flow: Jon Guerrera talked about how he uses gamification principles to make himself more productive.  In one example he talks about the effectiveness of setting a goal to write for 10 minutes a couple times a week.  The goal was achievable so he would actually do it and more times then not he would get in flow and end up writing for far more then 10 minutes.  On the other hand, when he set the goal to write for 30 minutes a couple times a week he would often not even start because even 30 minutes sounded overwhelming after a long day.  Other insights were around the value of physical prompts (post-it notes) and making rewards items not cash.

Treat your users (fans) right: Chamillionaire gave a very entertaining talk about how he engages his fans, also known as Chamillitary.  The main takeaway is that his fan base is very loyal because he treats them right.   Most musicians send platinum plaques to DJs to get more airtime; he sends them to his fans (a 12 year old in Iowa has one in his mom’s basement).  Most online reward systems give bullshit rewards like 20% off a purchase; he gives away jackets from music videos.   He focuses on authenticity and leverages that people want to be part of something bigger then themselves (The Chamilitary).

Design patterns for user engagement:  Nadya Direkova gave a clear, actionable talk on 16 design patterns for user engagement.  The 16 patterns all fell within the three of categories of come & try, bring friends, and come back.  Patterns that I found especially novel/interesting were gated trial and mischief.

Programming the programmers:  Jeff Atwood talked about how Stack Overflow is not a game in a traditional sense but simply sorting by a particular attribute (that he & the users care about).  People will want to be at the top of the page even if it’s not a traditional game rank.  He also had good insights around how a user’s reputation needs to be driven by what other users think about her, not time or the system.   He also advocated for giving power to the community and not allowing a user to judge others until she has earned status themselves.

Lean gamification: Keith Smith, founder of bigdoor.com, took a page from the lean startup movement and promoted a build, measure, learn approach to gamification with less grand strategizing up front.   He saw gamification as a way to increase both loyalty (returns) and engagement (time on site) and presented a familiar loop diagram consisting of onboard, yean, reward, social, and then back to onboard.

Come for the extrinsic motivators, stay for the intrinsic motivators: This theme was common across a couple of talks and is very relevant to many of the products I work on.  The basic idea being that big, extrinsic motivators like giveaways are great acquisition tools but are not sustainable over time for most companies (and are less effective on people over time) while intrinsic motivators around status and community are not great carrots for getting people in to a service but once they are in these become great ways to keep people engaged.

 

Turbo Tax urges you to not throw away money

I recently came across a clever use of loss aversion in the subject line of an email I received from Turbo Tax. The email, which is essentially a $25 coupon for Turbo Tax, warned me that if I deleted the email I would be throwing away cash.

An email with the loss aversion subject line

I thought this was a great example of a company using strong loss aversion language to get people to behave differently. I’m sure this email’s open rate crushed the standard “Get $25 off your taxes” subject line.