Pam, unknowingly sitting immediately behind the Firefox design team (Firefox also uses the tabs metaphor), was asking this of Google's Glen Murphy, who had just described the process of designing Google Chrome -- Google's new browser -- to a near capacity audience at PARC. Much of his description had been focused on the meticulous process of designing Chrome's tabs. But why tabs? Glen had said that the team had settled on use of the tab metaphor very quickly, emphasizing that it just seemed right to everybody. What other options were explored and considered?
Glen had repeatedly stressed the value of user research during the design process, saying that he couldn't overstate the importance of the many "cognitive walkthroughs, lab usability tests, and longitudinal studies" that were conducted. But did the team generate and seriously explore and test many concepts other than tabs?
Doing so is often an important part of a good design process, certainly one of relevance to the design of Google Chrome. Indeed, it reflects an application of "design thinking," something I've written about in previous posts (e.g., "Crummy innovation") and in interactions magazine (e.g., "On Addressing Wicked Problems..."). Business professionals are hearing lots these days about the importance of applying design thinking to business decision making -- a process typically dominated by analytical thinking.
But another good time to apply design thinking is, um, during product design.
Note that I'm certainly NOT claiming that it wasn't applied during the design of Google Chrome. For all I know, lots of concepts other than tabs were generated and explored. I should have asked. But I do know that the generation and exploration of multiple design concepts happens much too little in many engineering-centric companies.
I did ask a question of Glen. However, my question focused on the role product management played during this project. Glen had stated that the Chrome team was comprised of people from engineering, user experience, and product management (though he was not permitted to reveal how many from each).
Glen had also stressed the importance of the close relationship that was maintained among engineers, designers, and users throughout the project (see his slide to the right); for example, the engineers observed every user study conducted by user research personnel -- something which is, indeed, probably still far from the norm. I wanted to know what product management was doing during the project, since it didn't appear to be represented in that important slide (though I would tend to want to see it there).Glen had also emphasized the importance of the interchangeability of roles at Google, saying this was his first project in the role of designer at Google, having been in the role of engineer on previous projects. According to Glen, this interchangeability facilitated the important closeness of the relationship between designers and engineers.
But one can be in the role of designer without extensively applying "design thinking," which, again, I say WITHOUT implying that was true in this case. But when it is true or is likely to be true, there are things that can be done to increase its application.
At the recent CanUX workshop (which I didn't attend), Jerome Ryckborst presented an approach he developed for use in the company at which he works. Here is what Jerome said about this on the Vancouver User Experience discussion list in September:
"Over a year ago, our CTO decided we would not hire a designer to support our 100 software developers, and declared that the UI was ultimately the responsibility of developers. The problem I saw with this: developers untrained in design believe they're designing their software, but they actually aren't doing things that designers would recognise as design activities. I took this as a challenge because I didn't want Usability to be the mop-and-bucket brigade at the end of the development process. I set out to improve the outcomes of our developers' design efforts. ... With the help of my colleagues and the ideas of various experts, we assembled, tested, and refined an ideation-design process specifically for software developers.
You, too, can learn and use this process."
Jerome's CanUX 2008 slides, which describe his process quite nicely, are presently accessible on the CanUX 2008 homepage. Labeled "Five-Sketches-or-Else," the process consists of a series of activities (some of which are iterated) which facilitate the generation and exploration of design concepts, preventing settling on a single concept much too quickly.Also at CanUX 2008, Brandon Shauer talked about the sketchboarding technique I referenced recently in "Prototyping for tiny fingers." It, too, facilitates the generation and exploration of design concepts.
And there are other approaches that can be taken, some of which I've described in previous blog entries and where the best choice of an approach can depend on a variety of factors. But common to these approaches is facilitation of the approaches by "UX" personnel. As I've argued often (see, for example, "Soft skills"), UX personnel need to be able to play the role of facilitator of a good research and design process involving non-UX personnel as much as if not more so than doing the research and/or design themselves.
Is "design thinking" being applied during the product (or service) design process where you work? If you need some help with this, give me a holler.
