Iterations
Working in a completely open problem space is, among other things, an exercise in self control. When you’re a designer and you get the chance to invent freely, it is natural to jump onto the most interesting problems first, which are often the ones that can be solved through clever design. Whether or not these solutions would actually benefit users is a different matter altogether. Since the problem space for Project Tofino is as open as can be, we were working very hard on not making that mistake — on not jumping to conclusions too early. Instead, we wanted to start with the problems and desires that actual people had (read: people who don’t work in the technology industry).
Conveniently, our research team was way ahead of the task and had gathered a wide variety of insights into people’s online behavior over the past years. The most recent of those efforts was also one of the most significant ones: we call it the Workflows Research and we’ll publish more on the results soon. This research provided us with insights about usage patterns, frustrations and problem solving strategies that real people use to solve real issues.
Among the workflows we picked to investigate first were comparison shopping, saving for later (and contextual recovery), and improving recurring navigational patterns (a.k.a. making it more convenient to visit the sites you go to frequently). We’ll talk more about each of the problems and solutions in another blog post. For now, let’s dive into the methodology we used to work on these problems.
After discussing what we learned through research on a topic, we started concepting with pen and paper, going broad and exploring different angles on a given problem. The big question for the design process was how we could get solutions in front of users as quickly as possible while still making sure that we got genuine reactions. I am personally not a fan of paper prototypes for two reasons: first, we can’t test them remotely, and second, they immediately move people from the role of the user into the role of the critiquer. While that would still be valuable, we were sure that we could get more value out of testing by evolving our concepts into low fidelity mockups right away. In addition, the step of turning our paper sketches into something that looks like software forced us to do one more iteration on each design, often sparking new ideas.
Since we wanted to move quickly, we couldn’t build an entire browser experience for each feature or test. All our prototypes were vertical, meaning that they allowed users to take one very specific navigation path through them. In order to prevent people from anchoring too much on their current opinions on particular browsers, we also made sure that the prototypes didn’t resemble any major browser too closely.
Each prototype explored a small domain of ideas and over the past weeks we have developed, tested and iterated in a number of areas. Focusing on qualitative testing of rough prototypes allowed us to move faster, broadening our understanding of both the problem and the solution we’re designing.
The other approach we used was to test other products with users. When we found that some other software already had implemented a concept similar to what we were exploring, we skipped creating prototypes altogether and instead tested that product with users. This allowed us to gather valuable insights from actual users even faster.
Using this process, we have learned among other things about the kinds of information that people need the most when making a buying decision, what attitudes to expect towards contextually surfaced content and the different mental models that users had towards saving information.
We are now at the stage of combining those concepts into something that’s more of a coherent product. This is also the point in the process where we can start exploring some of the interesting interaction ideas that we have been holding back on so far, along with the ones that many of you have been proposing through our various channels.
