While Airbnb is data driven, they don’t let data push them around. Instead of developing reactively to metrics, the team often starts with a creative hypothesis, implements a change, reviews how it impacts the business and then repeats that process.
User-Centered Agile Development
For interactive systems in the 21st century, we must do more to understand how our users behave and what they need from our interactive solutions. Furthermore, these behaviors and needs must inform the design process without violating agile constraints (for example, no big design up front). To do this requires a few adjustments to a typical development process:
1. Integration of usability and user experience expertise with the development team
2. An appropriate amount of user research up front
3. The distillation of the user research to a suitable form for design (personas)
4. Parallel streams for interaction design and development
Mobile engineering and Design had about nine weeks to design, prototype, develop, test, and calibrate mobile.twitter.com for launch.
Mr. Zuckerberg takes a decidedly deliberate approach to product development.
That’s evident in how the 28-year-old CEO led the creation of Timeline […] The new feature was a culmination of an 18-month process that included dozens of test versions and multiple focus groups.
The group created at least 100 versions of the product, according to employees on the team.
Scrum (one of the most popular variants of agile) advocates you create a Product Backlog, a collection of stories that describe user needs. …
The UXI Matrix is a simple, flexible, tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams.
• If the designers of the conceptual model didn’t take the user’s mental model into account then it is highly likely that the product will be hard to learn and use.
• If there are multiple user groups and the conceptual model is designed to match just one mental model, then the other users will find the device hard to learn and use.
almost everything we do during a user-centered design process has to do with either:
1. understanding what the users’ mental models are (with task analysis, observations, interviews, etc), or
2. designing a conceptual model to fit the users’ mental model (interface design, iterations, validation testing, etc).
If we run an experiment large enough, we want to tell everybody, “Hey, we’re doing an experiment.”
One of the great things about working on products at Google is that we can try stuff out and launch it as an experiment and get tons of data. As a designer, I feel very lucky because I have access to enough data and enough users that I can actually get statistically significant information on whether or not something should be this tall, or this tall, or this tall.
Some designers, it drives them mad. But I think, if you knew that this mock-up is actually, objectively a better experience for people than this mock-up, you’d totally take that.
On the toolbar, this is actually a very complicated design problem. One of the dials that you’re turning is making it a functional, useful, discoverable tool. But other dial you’re turning is that you want to make sure you have enough space on a variety of devices and screens to make sure that the application [the user] is in is given as much space as possible.
Sometimes these trade-offs come into conflict. We have to do a lot of designs, a lot of experiments, a lot of iterations, and so in this particular case, we’re in the middle of that process. We’re trying some stuff, we’re looking at it, we’re seeing how it works, taking that learning, walking it back and iterating on that set of designs.
We’re pretty open about what we do, so we iterate in public a lot and try different things out. This is what happens on search in particular. We’re running tons of experiments all the time to tweak and fix and change.
We do a lot of user research, and we run a lot of experiments. The user research spans a pretty big spectrum. On the one hand, there’s a lot of generative, evaluative research. We go out into the field, talking to people, figuring out what kinds of questions they have about their world. What are things they want to know that we could provide as a search experience?
We [also] have research labs here on campus, and we invite users to come in and use the product. That’s much more qualitative research. Are we actually solving the user’s problem?
Sometimes new features or product directions can come from within the design team. This gets back to what I mentioned about our more exploratory research, generative research. We might go out in the field and just talk to users and figure out what kinds of problems they might have.
For instance, we did a study last year talking to people about questions they might have around medical issues. Medical queries [are] a really interesting space because there’s a high incentive to learn a lot of information. There’s a lot of judgment that has to happen in terms of the relevancy and quality of the content you can read on the Internet.
“We’re always continuously surprised by the kinds of questions people are asking and the kinds of answers they expect from Google search.”There’s an understanding issue, there’s all these issues around… [the user’s] awareness of this particular topic.
There’s some social issues at work. I might be doing the research for a family member or a friend.
We try to identify ways in which we can better support the users with these types of information. Maybe there’s a gap where they’re trying lots of different tools, or they’re not aware of tools that are available them in terms of search. So we try to figure out ways… to make a better tool here or make it more discoverable.
From a design perspective, we can take all that research and start telling stories. From there, we can talk to engineers and product managers and work together to create a solution, and then again it goes through that iterative process.
We brought 4 users in per week, and we did this for 15 weeks
Every time we come out with a drastic new redesign or big change that we think might make some users uncomfortable, or present them something that they’re not used to, we make sure to do a lot of user testing. We bring users in at every stage of the process, showing them everything from really rough paper prototype mocks to really basically the product is built. We just want people to come in and sit down and use it and get their reactions and ask them some questions about how the new change made them feel.
When we were getting ready to launch a new redesign or launch a new feature, we’ll bring people in. We already have a working version of the site. We can actually have them walk through it as if they were using it at home and witness their reactions, see where they’re getting tripped up in the process.
But more and more with some of our bigger releases, it’s been really important to do a lot of the user testing way, way earlier in the process. I’ll give you an example. Last December we launched a change to privacy and so when you logged into Facebook one day, you got a little privacy dialog that said, “Hey Facebook is making some changes to privacy. Please revisit your privacy settings.”
That thing is not going to take that long to build. Right? It doesn’t take that long to design, as far as it’s just one little dialog. But the process for us getting to that final point was months and months, because we knew privacy is such a sensitive topic for people that we wanted to be absolutely sure that what we were doing people would be comfortable with. It was the right thing to do.
I think maybe four or five months prior to our launch, we were already bringing people in. We hadn’t even started building the pod. It wasn’t really even designed. We were just showing them sort of a little text dialog with the language that we were going to use and with a lot of different options for how we would present this messaging to them.
These are like paper, low-fi prototypes, you know? Nowhere near what the final product will be. But prior to us even building and getting nice mocks from everyone, we already had at least five sessions with a bunch of users testing about 30 different versions of the language and the messaging for this dialog.
Then after we built it and we actually built like three or four different versions, and we brought another couple dozen users in to — now we have fewer versions, but we tested with more users. We wanted to make sure that this made sense the young tech savvy user, and the grandmother at home who just wants to communicate with her family and doesn’t want the rest of the world to see her family photos.
Twitter’s six design principles
Emphasize the moment • Be fast • Eliminate friction
Understand limits • Establish rhythm
Monitor trends • Adapt to behaviors • Be human
Listen to feedback • Build trust • Fight for our users
Be open & transparent
Aim for clarity • Make it obvious • Help, don’t hinder
Try new ideas • Think big • Iterate often