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

Like you, I’ve been to my share of presentations. I’m that annoying guy near the back who takes a lot of notes during it: jotting down the awesomeness, the nifty sound bytes, the structure, and the ideas it sparks. If the thing is failing, I’ll jot that down, too, and try to suss out the reason to make sure that when I present I don’t make the same mistake.

After years of doing this, I’ve come to group these successes and failures into four big criteria that every conference presentation ought to have. I’m going to share them with you now in the hopes that a) I’m right and b) more presentations will fall into the “awesome” rather than “regrettable” category.

This first week of August has been good fun from start to finish! Jim, Faith, and Rock Health agilely went from stories to a plan of action.

Alan's post on ideas, innovation, and creative teams reminded us of an interesting perspective on innovation from Clay Christensen and Art Markman about busting innovation myths.

We took a break to watch the Giants game with our amazing summer interns Mo and Brendan.

Today, Golden, Greg, and Jenea are doing their part at Device Design Day. Get some design goodness of your own at in the upcoming Visual Interface Design session August 15-16.

Other interesting scoops this week

Over the years, client organizations have taken this advice to heart, with more and more forming user experience teams that focus on assessing and meeting user needs. However, just having a seat at the table is not enough. As designers, we can help shape and facilitate the overall conversation.

To bring designs to fruition, designers need to collaborate effectively. While technologists and business executives value design, they often sense that design decisions are subjective and arbitrary. To get buy-in, designers need to help their partners understand design rationale and decision-making. Through collaboration and communication, designers can ensure that all team members have a shared understanding of the stakeholder objectives, the user needs, and the intent of the design.

Cooper now offers “Design collaboration & communication,” a course that sets the stage for collaborating on design and communicating design decisions. In two days students learn how to involve others throughout the design process, so that the design vision is agreed upon each step of the way. Communicating design throughout the process reduces the likelihood of other team members misinterpreting or altering the design during development.

The course covers the following topics:

• Designing workshops to conduct with stakeholders to ensure a shared product vision
• Choosing appropriate research methods
• Involving others in research synthesis
• Prioritizing what should be built based on business objectives, technical constraints, and user needs
• Articulating the value and benefit of design decisions
• Defending design without becoming defensive
• Determining the right level of documentation for your development process
• Moving the discussion from features and functionality to user goals and business goals

Whether you follow a traditional waterfall model or an agile development process, the communication and collaboration techniques in this course can help you gain buy-in for your design decisions.

This course provides great techniques for designers who want to create buy-in and build credibility within their organizations. The course is also great for cross-disciplinary teams of designers, product managers, and developers who want to communicate more effectively.

Our next public offering of this new course is July 25 & 26, 2011 in our San Francisco studio. A Cooper designer can also deliver the course at your office, and the content can be tailored to fit your particular needs around design planning and collaboration.

(This was originally published on Playwell, Alan's personal blog.)

Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Things I learned:

1. After 25 years, it’s time to lose the Windows computer and get a Mac.


2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.


3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.


4. It is time to build software.


5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.


6. When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.


7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.


8. Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).


9. Even this jaded old fart can still get excited about changing the world.


10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.


11. People want a leader with a vision.


12. Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.


13. The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.


14. For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.


15. Story-mapping is a major component of the bridge between interaction design and agile development.


16. Story-tracking software isn’t quite there yet.

It seems that language in software is on the mind of interaction designers. A few bright folks over at UX Matters have thought about whether software should speak to users from a first person or second person perspective. I have been thinking about similar issues after a client recently asked me about whether a piece of software should ever refer to itself. “If we already think about computers as other people, why wouldn’t we?”

What’s he talking about? For those unfamiliar with The Media Equation, in 2003 Stanford professors Reeves and Nass published a series of experiments they conducted which show that humans essentially treat computers as if they were other humans. From Publishers Weekly: 

"People are polite to computers, respond to praise from them and view them as teammates. They like computers with personalities similar to their own, find masculine-sounding computers extroverted, driven and intelligent while they judge feminine-sounding computers knowledgeable about love and relationships."

How do you thoroughly critique a design without crucifying the designer? What are ways of critiquing that result in better designs, rather than defensive justifications?

Scott Berkun explores a model for design critique in a detailed post, but I'm interested in the little stuff that works for your design team in day-to-day practice.

At Cooper, our teams often work together for a year or more. It is important for us to create a dynamic of cooperation, but great design often happens when we push on assumptions and challenge the first iteration. We want to encourage this critique, but make sure that it doesn't derail the meeting.

Why is that good?

It's pretty common to hear a skeptical Cooper designer begin a critique with some variant of the question, "Why is that good?" Many ways to express disagreement have negative effects on the meeting or relationship. "That won’t work because," or "But what about." These tend to bring momentum to a halt. Designers must stop, defend their ideas, or chase objections.

As anyone who has faced a blank whiteboard knows, once the ink gets flowing it is important to run with it and see where the idea goes. Communication strategies of design partners can enhance or detract from this process. By asking to see the goodness, we focus on enlightenment, encouraging our partner to help us see what they see. Also, asking an open-ended question is an acceptably naïve way of pushing your design partner to step up and show you what is going on in their mind.

At the core, we want our teams to feel comfortable in expressing healthy disagreement, and to focus on clarifying rather than justifying.

What are ways that your team has developed to critique design while maintaining harmony on the team?

One of the hardest things about being a designer is that we have to spend a lot of time and energy convincing people to believe in our ideas. Not only do we have to come up with a great idea in the first place, but then we almost always have sell that idea to a big group of people that you must work with to turn these great ideas into reality.

Of course, we all love to believe that the elegance of our vision is self-evident upon a simple walk through and that our beautiful renderings will stun our audience into adulation. Unfortunately, even if you're very good, this probably only happens some of the time.

The rest of the time we have to explain ourselves. We have to put words around our pictures in such a way that we get our audience to engage, consider and hopefully support our plans and schemes. And this better not be slight of hand. This is no political campaign—if you trick someone into believing you, they can always change their mind after they vote.

Lucky for us, this isn't a new problem. With its roots in the philosophical pursuits of the ancient Greeks, rhetoric is the study of effective spoken and written communication. It is based upon the idea that form and content may be distinguished from each other, and that certain common forms may be applied to communicate a variety of content. As boring and old fashioned as it might sound (kind of like learning Latin), I've found that returning to these basics can be invaluable in clearly articulating the kind of conceptual thinking that often forms the foundation for our proposed design ideas.

Even after you’ve sold them on personas, even after you’ve explained that you want to design for a specific persona first, even after you warned them about the perils of the “elastic user,” you can find yourself hearing things like, “Well, I know this guy who would do it this way...”

To help clients who won't be put off by pop-culture references, I reference the parable of The Homer.

For those who aren’t familiar with the Simpsons episode “Oh Brother, Where Art Thou?” (Season 2, Episode 15), it plays out like this: Homer meets his long lost brother Herb, who happens to head an automobile company. Believing Homer to be the perfect “everyman,” Herb instructs his designers to make exactly the car that Homer wants.

A friend recently told me that she was challenged by information management in the design process. "I'm looking for anything to facilitate faster communication…[it's hard to] remember all the people I have to contact to update about something. Sometimes I'll send out an email and forget the developer, or forget the QA person - and this happens vice-versa…not intentional for anyone. It's just hard to remember everyone in a fast moving environment. "

Communication is tricky. I have to say that face-to-face has advantages over other methods because you can tailor the communication, but it is time consuming. When face-to-face won't do, consider these questions:

• What are the most essential elements you’re trying to communicate and to whom?
• What are your objectives for the communication?
• What are the most effective methods to achieve that?

I’ve been hearing a lot about “visibility” at the Agile '08 conference. Development teams keep card walls that describe the work they are doing. Anyone can mosey up and see what’s happening. Designers can do a similar thing, by posting a timeline, and work product related to each step. Project wiki’s are also good for the running stream of work done. This is all “pull” communication that people can check in on when they are curious, or need reassurance about what your team is doing.

In my experience, “push” communication should be used sparingly, and should contain summaries and action items. People are busy and don’t have time to process a lot of email. Make your moments with them count.

What do you think? What works for you?