Where do you start when you're approaching a complex software design problem? If you work on a large development team, you know that software engineers and UX designers will often approach the same design problem from radically different perspectives. The term "software design" itself can mean very different things to software architects, system programmers, and user experience designers. Software engineers typically focus on the architectural patterns and programmatic algorithms required to get the system working, while UX designers often start from the goals and needs of the users.

In the spring of 2009, I participated in a research study that looked at the ways in which professional software designers approach complex design problems. The research study, sponsored by the National Science Foundation, was led by researchers from the Department of Infomatics at the University of California, Irvine. The researchers traveled to multiple software companies, trying to better understand how professional software designers collaborate on complex problems. At each company, they asked to observe two software designers in a design session. At my company, AmberPoint, where I worked at the time as an interaction designer, I was paired with my colleague Ania Dilmaghani, the programming lead of the UI development team. In a conference room with a whiteboard, the researchers set up a video camera, and handed us a design prompt describing the requirements for a traffic control simulation system for undergraduate civil engineering students. We were allotted two hours to design both the user interaction and the code structure for the system.

Jim Dibble and Ania Dilmaghani at the whiteboard in their research design session

As I'm sure you're thinking right now, two hours is not enough time to fully grasp the intricacies of traffic control, let alone to design the mission-critical software architecture and the user interaction model of a traffic control simulation system. As designers who approach problems from the user's perspective, Ania and I spent most of our allotted time considering the user's experience. We explored the real-world problems involved in traffic control and the tools that users would need to construct maps, set traffic light timings, seed traffic, and evaluate the results of a simulation run. We touched briefly on the way in which the simulation engine might work, but definitely did not provide sufficient detail to enable programmers to get started on the innards of the system.

The final whiteboard diagrams after the two-hour design session

Our team was selected for study

Several months after our design session, the researchers wrote to tell us they were planning a conference on studying professional software design at UC Irvine. They chose our design session as one of three to be analyzed and interpreted by invited participants. The organizers put the call out to researchers from a wide variety of disciplines, including software engineering, design studies, human-computer interaction, cognitive science, and psychology. Participants were given access to both the videos and transcripts, and were encouraged to analyze the design from any of a number of perspectives, including design strategies, design notation, interpersonal communication, decision-making strategies, comparisons to established software design methodologies, and design outcomes. Because the organizers felt that the conference participants would appreciate the ability to discuss their observations and theories with design practitioners, they invited us to attend.

In February 2010, we traveled to UC Irvine to attend the conference. Walking into a lecture hall with more than 50 researchers who had viewed our videos repeatedly, we had a small sense of what Brad Pitt and Angelina Jolie might feel like when walking into a restaurant in LA. Heads turned, and people pointed and whispered.

Researchers from multiple disciplines came from around the world, from as far away as Australia, Brazil, Japan, and Europe. Over a period of three days, we heard over 30 papers analyzing our design strategies, our communication patterns, and our final design solutions. And at the end of each day, we heard closing thoughts from luminaries in the fields of computer science, design studies, and psychology, such as Frederick Brooks (professor at UNC Chapel Hill and author of "The Mythical Man-Month"), Nigel Cross (design studies professor at The Open University, editor of Design Studies, and author of "Designerly Ways of Knowing"), and Michael Jackson (computer science professor at The Open University and author of "Software Requirements and Specifications").

The panel of luminaries speaks at the close of the conference: (L to R) Michael Jackson (The Open University), Mary Shaw (Carnegie-Mellon University), Clayton Lewis (University of Colorado, Boulder), Nigel Cross (The Open University), Barbara Tversky (Stanford and Columbia), and Frederick Brooks (University of North Carolina, Chapel Hill)

The three design teams had taken very different tactics in approaching the design problem. Because we came from a user interface background, our design strategies focused on exploring the problem from the user's perspective: how does traffic signal timing work, and what tasks do civil engineering students need to perform to gain a better understanding of traffic signal timing? The other teams, composed of software architects, worked from the inside out: how does traffic signal timing work, and what architectural patterns can be used to implement the traffic simulation system? While one of those teams touched briefly on the user interface, the other team completed their architectural design in an hour, waving their hands to indicate that all that remained was a basic user interface design.

How our design fared

So, how did the researchers assess our designs? Well, their evaluations depended on their research perspective. Several computer science researchers evaluated the design session based on the technical skills exhibited: the ability to accurately frame the technical problem based on the explicitly stated requirements and the ability to choose an appropriate architectural pattern for the implementation. Design studies researchers tended to evaluate the design on the "soft skills" associated with design: interpersonal communication, ability to articulate the reasoning behind design choices, and the ability to examine and evaluate requirements based on the end-users' needs. Other researchers, rather than being prescriptive, examined the processes and strategies used by the design teams: how did the designers structure their design sessions, how did they explore the breadth and depth of the problem, and how does this compare to the way that the academy teaches software design students to approach problems?

Not many designers have the opportunity to hear a team of cross-disciplinary researchers examine their work. We heard much in those three days, reminding us of the importance of explicitly planning a design session, of framing the design problem, and of conversation as part of the design process. Throughout the workshop, we also passed on our observations to the researchers, letting them know that real-world design problems seldom begin from a complete problem statement or requirements document, and that architects and developers can easily jump to the system's architectural structure while overlooking the user's goals, needs, and outcomes.

Mary Shaw and Frederick Brooks discuss the conference proceedings during a break

After the conference, Ania and I discussed how differently the design session might have turned out if either one of us had been paired with a software architect. We definitely would have spent more time addressing the system's architecture, but we were unsure whether we would we have been able to frame the problem around meeting the user's needs. In engineering-led organizations, designers are seldom included in early-stage design sessions, which can lead to products that don't meet the target users' needs. Collaborating with engineers and architects in early-stage design can be incredibly difficult because we often don't share the same criteria for evaluating design decisions. While many engineers are starting to express requirements in more user-centered ways, for example through the use of agile user stories, they often have difficulty moving these beyond low-level narrative that describes the purpose of technical features.

Read more

Several publications have come out of the work of the conference, including a special issue of Design Studies (Volume 31, Issue 6, November 2010), a special issue of IEEE Software (Volume 29, Issue 1, January/February 2012), and a forthcoming book on studying professional software design. Because of our participation in the conference, the researchers encouraged us to write an article based on our experiences in software design, for the special issue of IEEE Software. Our article, Strategies for Early-Stage Collaborative Design, (Ania Dilmaghani and Jim Dibble, "Strategies for Early-Stage Collaborative Design," IEEE Software, vol. 29, no. 1, pp. 39-45, Jan./Feb. 2012, doi:10.1109/MS.2011.124), offers a set of ten ground rules for conducting collaborative design sessions. In our article, we encourage engineers and architects to develop the "soft skills" of design, and to evaluate design solutions against user needs and scenarios. These ground rules, based on our experience and our learnings from the conference, will be helpful to anyone running a collaborative design session, whether UX designers or software architects.

The experience has us thinking about early collaboration outside the research laboratory. UX designers and software architects each bring unique understandings to problem-solving. Depending on how an organization structures design work, these differing perspectives can be either complementary or conflictual. We're familiar with how it works in our business, and curious about how it works in yours. How does early-stage design work in your organization? Do your interaction designers and architects work collaboratively from the outset to understand the problem? How do you establish a feedback loop to bring understandings from each design approach back to the overall solution?

What do you think? Join the conversation in Comments

At the start of the new year, we're looking to discover how we can grow and improve as designers. .net Magazine proposes some interesting new year's resolutions for designers. To this list, we've add a few of our own:

Inspired by the Dieter Rams exhibit at SF MOMA, Kim Appelquist resolves to foster relevant design and a heightened awareness of symbiotic coordination. Dieter Rams, Braun phonosuper (SK 4), 1956; design: Hans Gugelot and Dieter Rams, photo: Koichi Okuwaki

Chris Noessel resolves to empathize even more with users, such as trying out a tool for better understanding the needs of the elderly by wearing a suit that makes you feel 75 years old.

Peter Duyan resolves to look beyond standard interface paradigms, to possibilities such as multitouch on any surface with a contact microphone.

And we all resolve to extend our impact as designers, whether it's through conveying the value of designers who code, or being the new secret weapon for start-ups.

And as January gets underway, we're happy to share the release of our most recent work with Thomson Reuters on their new mobile newsreader app for the iPad. Thomson Reuters provides real-time news and information to financial professionals around the world. Cooper designed an iPad app that facilitates the creation of a list of news topics, companies, trends, people, or ideas that interest them, and then populates these with relevant market data and up-to-the-minute analysis. The first version of this app is now available in the iTunes store for Thomson Reuters subscribers.

Here's to great design in 2012!

What do you think? Join the conversation in Comments

Have you ever used a public service that understood your needs? We all have horror stories of waiting in seemingly endless lines at the DMV or hunting forever to find the information we need on poorly designed city websites. Who is making sure that government uses effective design and technology to meet the needs of citizens in the 21st century?

Introducing Code for America

Code for America is a brand new non-profit that is taking on this challenge. And part of the challenge is understanding the target users of the technology. To help in that effort, Suzy Thompson and I taught a day-long workshop on Research for UX Design to the fellows at Code for America.

Code for America signage at their offices in San Francisco, autographed by the 2011 fellows

Code for America helps local city governments leverage the power of the web to become more efficient, transparent, and participatory. Built on a model similar to Teach for America, CfA encourages developers and designers to apply for a year-long fellowship, during which they will create open-source technology solutions for city governments. Out of over 300 applicants, CfA chose 20 fellows for their inaugural year, from a wide variety of backgrounds including Web 2.0 startup entrepreneurs, developers for local city governments and school districts, open source contributors, a researcher for the New York Times, a digital journalist, an intellectual property lawyer/programmer, and a museum exhibit designer.

Code for America 2011 fellows (image used by permission from Code for America)

Code for America Institute

The fellows are spending the month of January in San Francisco at the Code for America Institute, learning from guest speakers about a wide variety of topics, including treating government as a platform (Tim O'Reilly), building local communities (Danielle Morrill), being a change agent and nurturing social network communities (Caterina Fake), and taking an entrepreneurial view of their city projects (Eric Ries).

Host City Projects

Each of the fellows is assigned to one of four city teams, each with a target project:

The fellows will spend the month of February in their host cities, learning about the IT infrastructure and interviewing city stakeholders and users of their system. They will return to San Francisco in March to design and develop the open-source applications. They will present and hand-off the applications to their host cities in the fall.

Cooper Training

Because Cooper has extensive experience connecting user research to product design, Code for America asked us to come in and present a one-day workshop. From our courses on interaction design and design communication, we carved out a day's worth of materials on finding stakeholders and users, preparing an interview instrument, conducting interviews, debriefing interviews, and synthesizing and presenting research findings. We also gave them a look-ahead to personas, scenarios, and framework design.

The fellows got a chance to plan an interview instrument and conduct a 45-minute interview with members of the CfA staff. Conducting good ethnographic interviews takes practice -- I think the fellows came out of our workshop with a sense of confidence in talking to their city stakeholders and application users in February. I look forward to hearing about what they learn about their users, and to helping them create personas and scenarios from their findings. And I can't wait to see the amazing applications that result from their work.

Great Government Research and Design

A question to our readers: Where have you seen user experience design principles applied to government applications or services, to achieve an amazing outcome? At Cooper, we're currently working on a project with CalSTRS (California State Teachers' Retirement System), and in the past have done pro bono work with the SF Department of Health. I have also read about fellow Cooperista Renna Al-Yassini's service design work for the Roudha Center in Qatar. What user experience design work in the government or social service sectors has impressed or inspired you?

What do you think? Join the conversation in Comments