Beneficial, ubiquitous interactivity

Earlier this month, I dropped by an exhibition of masters student projects from the "Theory and Practice of Tangible User Interfaces" course at UC Berkeley. While waiting for the exhibition to open, Liz Goodman, teaching assistant for the course (that is her to the right side of instructor Kimiko Ryokai in a photo from the San Franciso Chronicle) told me about students' desire in this kind of course to take on projects of great importance, though such projects are often very difficult to figure out. Liz's words reminded me of some of Jon Kolko's words from our September+October 2008 edition of interactions cafe (in interactions magazine) entitled, "On Addressing Wicked Problems...":

"When I used to teach, my students would become enamored with the possibilities of design, and would make grandiose, and unintentionally trivializing statements like 'World hunger? It's just a design problem; we could solve it, if only we had the right model...'"

According to Liz, the challenging project of greatest popularity this year involved monitoring home energy use. However, only one group of students stuck with such a project, creating a demo of an energy monitoring system interface via which residents of an apartment building could see how much energy is being used in different apartments. The visual display showing energy use by apartment -- to be placed in a common space of an apartment building -- did not reveal the identity of any apartment unless an apartment resident approached with a device which enabled the display to identify only his or her own apartment. The student designers wondered whether multiple residents would take the opportunity to approach the interface simultaneously to discuss their relative energy use and what might be done to lower it and that of others.

(Two energy monitors for use inside a home were among products already on the market reviewed by James Pierce and David Roedl in "Changing Energy Use Through Design," the cover story of our July+August 2008 issue of interactions magazine. One of them is the Wattson home energy monitor pictured at left, which, among other things, enables people to be peripherally aware of their energy usage via the color and pulse of its mood light. "The novelty of this ambient energy awareness may stimulate reflection, behavioral change, and conversation.")

The foci of the other UC Berkeley student projects were very different, ranging from digital shadows of personal information that follow people around to cafe table surfaces that remember and remind you of how you make use of them. A mockup of a system via which students can unobtrusively communicate their views of the appropriateness of the pace of a class to its instructor reminded me of a system developed by Eric Paulos via which conference attendees can use their cell phones to communicate their presence or absence in the conference hall, how they are feeling, or their vote on an issue raised by a speaker; for both systems, the individual communications impact a display visible to all attendees, such as the display of attendees pictured at the right.

Eric's system was used during the Interactive City Summit held in San Francisco during 2006, an event that critically examined the rhetoric comprising "a future vision filled with beautiful, delicious urban technologies that will sooth the souls of our communities, generate playful neo-geo-landscapes, and celebrate our omni-connected harmony." The summit immediately preceded "a global festival of art on the edge" a few miles south of San Francisco in San Jose, where just a week and a half ago was unveiled a large piece of art consisting of thousands of LED lights that change color and pulse and pattern in response to codes communicated via the phone of anyone who chooses to call. The artwork, called "Show your Stripes," occupies the surface of the outside of a high-rise building.

Will "Show your Stripes" sooth the souls of the San Jose community?

An interactive light installation in the U.K. perhaps achieved this type of goal and other important goals much more. From "Dancing in the Streets" (interactions, May+June 2008):

"How do you transform a city center at night to enhance the experience of residents and visitors and to combat the public's fears over safety and security at night?

This challenge was set by York City Council’s ‘Renaissance Project: Illuminating York’, and we took them up on it. We made it our goal to get pedestirans to engage with our interactive light installation, and to get them dancing without even realizing it.

People out shopping or on their way to restaurants and nightclubs found themselves followed by ghostly footprints, chased by brightly-colored butterflies, playing football with balls of light, or linked together by a ‘cat’s cradle’ of colored lines. As they moved within the light projections, participants found that they were literally dancing in the streets!"

A video of this dancing is available on the interactions website. And you can read more and watch a video about some of the UC Berkeley student projects in an online San Francisco Chronicle story entitled, "Tangible fun at UC Berkeley's virtual projects."

(Note that according to Liz, one of guest speakers during the UC Berkeley course was her husband, Mike Kuniavsky, whose presentation in class was based on an article of his entitled, "User Experience Design for Ubiquitous Computing" from the November+December 2008 issue of -- you guessed it -- interactions magazine.)

Applying "design thinking" to, um, design

"The Omnibox is really great; thanks for coming up with that" said my friend Pam from Tuesday evening's BayCHI audience. "But what's up with the tabs? I've watched numerous people be confused by and just ignore them. Do people really use them?"

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.