Buzzkill

I’ve been struggling for days to put into words my reaction to the launch of Google Buzz. But the phrase I can’t get out of my head is “HOW could they screw up THIS MUCH?”

Well here’s how: Google took Gmail, one of the most widely used web services on the planet, and modeled a quantum change in its behavior with an insulated, private, corporate, top 1% tech-savvy user base.

Google Buzz creates an instant social network based on your email history. Google engineers wrote an algorithm to analyze years of correspondence in users’ Gmail accounts. At launch, by default, these associations were automatically linked and shared with everyone else in your "network." [Google has already modified the default behavior twice in response to criticism].

Apparently, Google tested Buzz internally for months prior to public launch last week. Unfortunately, the controlled conditions of corporate email are a poor stand-in for conditions “in the wild” of a public email service.

You could imagine that the post-launch backlash could have been anticipated with a bit of forethought, even an afternoon meeting that went something like this:

AGENDA
1. What types of people use Gmail?
2. What do they use it for? Who do they communicate with and why?
3. Does our internal beta account for those types of uses?
4. If not, how do we introduce this service to people who aren’t like us?

At a bare minimum, identify a set of people who represent a cross section of users: A grandparent who switched from AOL; a high school junior with an active and evolving social circle; a struggling factory worker in a hostile political environment; a professional with a secretive private life.

Then, just as a sanity check, ask “Is there anything problematic with mining the history of their person-to-person emails and creating a single transparent group from that list?”

For many things, Google’s approach—develop, internal beta, release, measure, adjust—is an adequate way to stumble towards a better experience. That approach takes good ideas, puts them in play, then sands down the rough edges and suggests enhancements. For something as significant as combining email and social networking, it’s toxic.

 

What do you think? Join the conversation in Comments

Interviewing Kids

I recently had the opportunity to return to a place I hadn't been for quite some time--the principal's office. My last project included interviewing 11-17 year olds about their homework habits, and I needed a hall pass from the secretary. In preparing for the interviews, it occured to me that I hadn't spoken to many 'tweens since I was one myself. Would they call me Mister? Ask to trade Bakugan? And the high school kids--would they be too cool to talk to me, answering every question with nothing but a yes, no, or dismissive smirk?

As it turns out, interviewing school-aged children isn't too different from interviewing adults. But as I learned, there are a few do's and don'ts you might do well to keep in mind.

Have an adult introduce you to the child
Allow a parent, teacher, or guardian to make initial introductions. This establishes your credibility to the child and communicates the adult's consent for conducting the interview.

Treat kids like regular people (that is, like adults)
Kids can tell if you're being patronizing and will adjust their own behavior accordingly. Treat them as you would any interviewee, thanking them for their time and explaining what they should expect from the session.

Interact with them at eye level, but don't get too close
Minimize physical power dynamics by sitting in a chair or kneeling alongside kids when you conduct the interview. At the same time, be aware of their personal space and don't give them a chance to feel vulnerable or uncomfortable with your presence.

Be specific with your questions
Kids tend to be quite literal in adult conversations, so be direct with the questions you ask and the responses you give. Don't be surprised when you point to a toolbar and say "what do you think these do?" and the response is "save saves, print prints, open opens, and delete deletes."

Avoid technical and professional lingo
You've picked up a career's worth of acronyms and jargon that your interviewee will not be familiar with. Also, look for the words kids use to describe things, and use those both in your interviews and when designing for your young audience.

Don't ever take pictures or video without parental permission
There are many legal and ethical issues around photographing and videoing minors, and if you don't have a clear need for it, don't bother. If you do ask, be prepared to take no for an answer without any further discussion. Put parents/guardians at ease with things like "we only use these internally for reference" and "don't worry, this won't end up online or on TV." When appropriate, set up your video to capture the session without recording the child's face, for example by training the camera on the screen when discussing software.

Don't crack jokes or be sarcastic
Kids won't be prepared for casual joking, for as much as you work to set up a peer relationship they are still talking to an unknown adult. Jokes will often be misinterpreted as serious comments. As an example, I was running a feedback session with a powerpoint deck that ended with a blank screen. When one child clicked past the last prototype slide and into the blank screen, I remarked "OH! You broke it!" then spent the rest of the interview making him feel better that he hadn't just busted our computer.

Recognize when an interview isn't going well and finish it quickly
This happens with adults too, but sometimes you'll get a kid who just isn't able to converse with you. Spend a minute or so looking for an opening, and if you can't break through, let them out of their misery and end the interview quickly. Don't abort it or say it's not working, just ask a few easy, obvious questions, thank them for their participation, and move on.

What else?
I'd love to hear more about other people's experiences interviewing children and involving them in user feedback sessions. What advice do you have?

 

What do you think? Join the conversation in Comments

Is Interaction Design a dead-end job?

IDEO’s Bill Moggridge made a comment last week after a screening of Objectified that hit close to home. To paraphrase, he said interaction design has become pervasive, that anyone and everyone can be an interaction designer, and so the role of professional interaction designer is (or is becoming) unnecessary.

So, is Interaction Design a dead-end job?

As an expertise, no. But as a discrete service offering or a career path, I say absolutely.

This position has not made me any new friends around the office, but to be clear, I'm not suggesting our profession is akin to flipping burgers at the mall. Instead, it's that interaction design has reached a point of maturity where growth is constrained. I see three major factors behind this and hope that by acknowledging them we can find a way forward.

Continue reading...

Software is a movie, not a building

In a previous post I suggested that film making is a good analogue for discussing software design and development, that lessons learned there could help us think about better ways to approach our own projects. I established the similarities like this:

Much beer has been spilled over comparisons of software to physical architecture, and while the analogy is interesting it is inherently flawed. For the industrial-age activities of designing and constructing a physical building are vastly different than the post-industrial process of designing and building a digital artifact of conceptual ideas, where cost is measured by time rather than materials and success measured by consumption and desirability.

Continue reading...

Goals! Prototypes! Action!

A thread in comments on a post from Michal Migurski got me thinking about the analogy of film making to software design and development. The more I explored the idea, the more multi-faceted the analogy became.

Movies and software are both very creative and very custom-craft intensive. They are both extremely collaborative — moreso than almost any other endeavor. Both encompass a wide range of styles, audiences, scale, and budget. For each there is a relatively subjective determination of completeness, that point at which the product is ready for release. And history is littered with spectacular successes, and failures, both within and outside the formal "system."

We can learn a lot by looking at parallels between film making and software, if only to recognize the issues we face around budgets, timelines, clarity of direction, conceptual and tactical authority are not unique. We can recognize that there are numerous models to adopt or avoid as the situation demands. It allows us to examine the interplay of money, talent, ego, authority, collaborative energy, role specialization, and market forces at a comfortable distance while learning lessons applicable to our own work.

To begin, let's establish a basic model that compares the film making process to the software making process. In a loosely time-based perspective, consider these parallels:

Naturally, there are countless variations to this flow, with more or fewer steps, multiple feedback loops, things happening in parallel, and so on. Moreover, countless questions that fall out from this comparison:

• Is there a parallel in the world of software to a screenplay?
• How do the roles in film making relate to the roles of software?
• Which types of movie productions are similar to the various types of software projects?
• How are feedback, iteration, and evolution handled in film vs software?
• Who exerts creative control, assesses market viability, predicts audience acceptance?
• How is technology changing established ways of working?

I'll explore more of these in subsequent posts, but for now, I'm curious to know if this analogy seems useful. Are there other lessons that can be drawn?

 

What do you think? Join the conversation in Comments

Meeting the expectations of the design

At Cooper, we’ve historically advocated a clear and explicit separation of interaction design and software development efforts. Underlying this position is the assertion that the job of interaction designers is to serve as user advocates. We approach the design problem not by asking “What can we deliver?” but “What do people desire?”

We’re guarding against the urge to focus on the development and delivery of software, hardware, and services before we understand its value to the humans using the system. By no means does that suggest our designs should ignore business and technological factors, only that our designs should be influenced primarily by our the motivations of the users represented by our personas.

The design must meet the needs of its users, and it follows that the product’s creators (designers, business folks, developers, etc.) deliver a product that meets the expectations of the design.

But how to design so that those expectations can be met? It’s a delicate balance. Ideally, there is a healthy interplay of possibilities and limits between the business factors, technology issues, and design motivations. Each group shares the goal of delivering the best product possible with the time, budget, and expertise available.

Here are some ways to keep a user-centered focus without losing sight of the factors that influence development:

Understand the business situation

Get a clear sense of the breadth of the design mandate: Is management pulling out all the stops to create a category-killer, or have they set a firm cap on the time and resources available to the project?

Know your medium (but not too well)

Understand enough about the technologies underlying the product so you can leverage things it does well without falling into the trap of designing to technical capabilities rather than user needs.

Listen to developers’ concerns and ideas

Recognize that every one of your design decisions impacts the work developers will need to do to implement and support them. Solicit their input on the design’s feasibility and seek their advice on ways to make the design more achievable. Your concern should not be that you’re signing developers up for hard work (after all, solving hard problems is what being a developer is all about)—it’s signing them up for unnecessary hard work.

Don’t concede your personas’ needs to business or technological limitations

If you’ve done your homework, you know what the product needs to do (and not do) to satisfy its users. If technical or business issues are in conflict with a persona’s needs, speak up. Demonstrate the value of your design to business and technology stakeholders to help them see the merits of accommodating the design intention.

Pick your battles

Be comfortable with letting some technology and business considerations trump design ideals. There are situations where a less-perfect standard implementation of one feature means more time to develop a custom feature that truly delights your users. Too many of these is death by a thousand cuts, but everything doesn’t have to be ideal for the things that really matter to be fantastic. The reconciliation of technology, business, and user-centered design is ultimately a business decision. The most fabulous design will never see the light of day if it doesn’t meet business objectives or isn’t technically feasible. By understanding the business and technical landscape, working across disciplines, advocating for your users’ needs, and knowing when to compromise, you can produce successful designs—successful because they meet the needs of users and the needs of developers and business stakeholders.

 

What do you think? Join the conversation in Comments

The virtues and perils of the developer/designer

How important is it for interaction designers to be well-versed in the technologies they are designing for? Does good design spring from a firm understanding of the underlying capabilities and limitations of the technology? Or is it helped by an indifferent stance towards how a design is ultimately produced in order to consider the issues from a fresh perspective?

There are good arguments on both sides of this issue, and there’s no one right answer.

Many successful product design models rely on designers being fluent developers. Notably, 37signals can rapidly develop and iterate their products because the design thinking is intertwined with its technological manifestation. A firm like Stamen delivers such compelling visualizations because they can ingest and process data like developers then exploit their tools to consider and present the information and interactions like designers.

Other models feature greater role specialization. At Cooper, we have designers with varying levels of technical expertise, from ex-programmers to design-school grads with no development experience. We work to keep the consideration of technological possibility or constraint at arm’s length early in the design process in order to envision the best experience for our personas. As our designs progress, we work closely with the client’s development organization to vet feasibility and adjust the design in response to developer and business stakeholder feedback.

Several factors have made the question of this design/develop relationship more complicated than ever:

• Agile devlopment methods that stress iteration and feedback
• Development tools that make it possible for non-programmers to build prototypes, demos, even shipping code
• Increasingly dynamic interactions that are difficult to design and communicate without experiencing
• Increased awareness of goal-directed design methodology by software developers

Where do you and your team fall on this spectrum, and how are you dealing with these issues?

 

What do you think? Join the conversation in Comments

Google Chrome: The interface is beside the point

There's been a lot chatter around the office and internet about Chrome, the recently launched (or leaked) Google Web browser. I've got to say that much of it misses the aspect of the application that I find most inspirational. Google Chrome exists for one reason and one reason only: To provide a framework for web-based applications to look, feel, and act like desktop applications.

It doesn't seem that Google has real interest in replacing IE or Firefox as the dominant web browser. (The tech business press can't see beyond this point). Instead, Google wants to see the technological underpinnings of Chrome adopted by mainstream browsers. The Chrome team is explicitly inviting other browsers to use their code base — they've open sourced everything — and they have explicitly acknowledged adopting best-of-breed UI features from others.

So how does Chrome elevate web apps to desktop app status? Six ways: Separate processes for each tab; Google Gears for local storage, offline functionality and "native app" behaviors; application shortcuts; a modern JavaScript virtual machine; and minimal-to-absent browser interface, aka "chrome". Let's look at each one in more detail, with snippets from Scott McCloud's fantastic graphic novella product tour.

Continue reading...

Mimicking the physical

Many a software app has gone down the dead-end of attempting to recreate physical controls and affordances. (See the rich sub-genre of notebook apps with spiral binding and turned-up corners.) But sometimes the clarity and familiarity of a physical analog is just the thing. The key is to use it as a starting point, not to slavishly recreate the physical experience in its entirety.

A good example of this is the new audio capture app, TapeDeck. Modeled after an 80's-era cassette recorder and its collection of tapes, TapeDeck addresses a key issue in audio recording — the difficulty of distinguishing audio tracks in a visual world. Each recording is represented by a separate cassette tape, organized by date in a slide-out drawer called the Tape Box. It also gives a clear indication of state, running the tape spools in sync with the big push-button controls. Plus, it's just fun to use.

Continue reading...

Algorithm Ink: Learning by doing

Aza Raskin has released a wonderful new toy, Algorithm Ink. As he states in his introduction, it really lowers the bar to exploring the creative mathematical beauty of fractals. Aside from the images themselves, there are two things I love about this site.

First, the less-is-more UI design really lets the canvas be the focus of attention by keeping tools out of your way until you need them. Second, and more fundamentally, is the “view source” ethos and the direct manipulation of the visualization-generating code that really makes the experience compelling (if not addictive).

Here’s what happens to me: select an interesting image and watch it play out. Click open the “edit” panel to expose the surprisingly few lines of code that make it tick. See all the pretty numbers. Change one. Click “draw” and see the effects of your change. Repeat about a thousand times.

Before I realize it, I’m copy-pasting functions from other drawings, following the logic in code to reverse-engineer how an effect is generated, musing on the power of weighting the randomness of my results. Like writing HTML on the Web 1.0, I’m learning by example and trial-and-error. Sure, there’s a manual for the syntax somewhere, but the experience of seeing and affecting the code in action is so much more fun.

 

What do you think? Join the conversation in Comments

Seeing patterns in research findings

We’re always on the lookout for engaging ways to communicate the patterns we uncover in our research. What factors cluster into significant groups? What are relevant attributes and relationships? What trends do we see?

Shan Carter and Amanda Cox at the New York Times recently produced a fantastic interactive chart highlighting the voting patterns along several demographic factors in the Democratic primaries. (You can read more about this graphic from Shan Carter here.)

I love the idea of starting with this approach and overlaying additional factors to draw out relationships and relative importance. In the Times example, imagine the squares drawn in relative proportion to the number of delegates in play; color and saturation representing the percentage of Democratic votes in the 2004 presidential election. Combining multiple factors does complicate the visual, so care must be taken to preserve the clarity that makes it so effective.

At Cooper, we often do something similar, with behavioral variables of interview subjects plotted along major axes, combined with demographics like age, organization type and role, to paint a picture of the interrelated web that helps us make meaning of a diverse human population. We always try to walk through these visualizations with a story that ascribes meaning to the observations, but providing clients (and ourselves) with an opportunity to interact with the data in a well-curated way really emphasizes the relevant factors and helps everyone understand the patterns we use to drive decisions and take action.

 

What do you think? Join the conversation in Comments