Aurora: Inside the Design Process and Concepts
by Jesse James GarrettI’ve written before about Adaptive Path’s open design sessions: regular open-invitation forums that allow project team members to draw on the perspectives of everyone at the company, and allow everyone to learn from projects other than their own. In a typical project, the team might have the opportunity to hold two or three open design sessions. For the Aurora project, we knew we’d need a lot more input than that. So we instituted weekly open design sessions, carrying us through from the earliest feature brainstorming to developing ideas for the visual design.
These sessions were an invaluable vehicle for collaboration between Mozilla Labs and Adaptive Path. Every Friday afternoon, we’d spend a couple of hours with a rotating group of contributors from Mozilla, talking through the design ideas we’d been coming up with, and seeing how those aligned with Mozilla’s own thinking about the future of the browser.
Early in the project, when we were still trying to give shape to the features and functionality of the future browser, these sessions were more freeform and speculative, and to an outside observer their connection to the ultimate design work may not have been obvious. But for us, this process was an invaluable tool in defining for ourselves the landscape of possibilities.
In between the open design sessions, Dan Harrelson and I would incorporate the input we’d received into our almost-daily collaborative work sessions. Usually, each of us would have some facet of the problem that had been nagging at us since the last time we met, and we’d take turns talking through those issues, sketching endless possibilities on whiteboards.
Much of this process involved questioning our own assumptions about what would and wouldn’t work. Although human behavior doesn’t change at a pace anywhere near that of technology, we did think that we could expect people to adapt some of their behaviors (and maybe adopt some new ones) as technology continued to evolve. The big question was which behaviors were long-term ones, and which were ripe for (relatively) short-term change. For every idea that made it into the final design, we probably discarded a dozen alternate approaches.
We found many of the design concepts difficult to document. Our usual tools like wireframes and mock-ups just seemed unsuited to an interface as dynamic as Aurora. Because so many of the conventions of interface design didn’t apply to Aurora, I developed a “design concepts document” that described the basic principles of how users would interact with Aurora and how elements of the interface would behave, so that Kumi Akiyoshi and Sebastian Heycke, who were responsible for the visual design of Aurora, could be sure they understood what we were trying to accomplish. This document evolved into a considerably simplified “interface guide” that summarized the various interface elements and how they work together.
For more detail on the Aurora design:
Aurora Design Concepts
Aurora Interface Guide