Version Three, Dec 2006, by Lynn Cherny

Twenty Observations on Corporate Software Design

    Design Talent
  1. Not everyone can be a good designer. Some people can learn some of the skills, but not everyone has the same capacity for excellence. This makes it hard to hire well, because you need to be able to screen for capacity and talent.
  2. Good designers see many possible solutions to most problems. They may bring old ideas back in a new form in new situations. Inspired design is often just the trick of applying an abstract idea from an old situation to a new situation, by seeing the similarity of circumstances.
  3. Good design can't be learned from reading books. Design expertise requires practical work as well as ability. UI design work usually entails exercising specific problem solving skills and often involves using specific deliverables at different stages of fidelity; these are recognized in some companies because they've proven useful as units of analytic communication for teams doing development.
  4. Competent designers know what they don't know; they learn from exposure to many products, to different kinds of problems and solutions, from observing usability tests, and from hearing customers talk about their tasks and from reading product reviews. Good ones will be very self-critical of their own work.
  5. Making design decisions can be very hard. This is because there is sometimes no single right answer. All the options you can imagine will have pros and cons. Ration your team energy for the issues that are most critical to resolve and let the experienced designers make the final call on the most vexing matters. Don't waste time fighting about radio buttons and checkboxes: chances are this is a big waste of team airtime if you have a designer on staff.

    Usability is Not Design
  6. Usability testing is not design. Usability testing reveals problems-- with software, with mockups, with tasks, with selection of subjects for the test-- but it doesn't reveal solutions to problems. It doesn't even reveal causes of problems, which is the most often misunderstood aspect of usability testing. Causes may remain forever unknown for some usability problems, but that doesn't mean you shouldn't try to find a way around the problems if there's enough evidence they are a threat to your customer.
  7. "Usable" is not sufficient for "well-designed." Well-designed goes beyond adequate and into the realm of elegant. This is the new product design chic we all want at the best companies.

    Technical and Teamwork
  8. Design decisions happen at many stages of software development: Basic architecture, code style, programming language/tool choice, control and dialog layout, proposed and/or implemented functionality, workflow of the application, event handling, error handling, string choice, icon choice, color palette, marketing materials... In the best products, aspects remain coherent and consistent. If no one is paying attention to these levels for coherence or quality of the end result, the overall product user experience is at risk.
  9. Design of software is necessarily technical at some levels. Design discussions sometimes run up and down the detail spectrum, because the engineers involved in the design discussion are naturally concerned about what's implementable. This is okay. The degree to which the participants can zoom in and out, but not get derailed into minutiae and forget the big picture, is the degree to which your design management and teamwork are effective.
  10. Design of software is necessarily non-technical, too. Your users don't care about how you implemented it or why you did it that way (unless you ship code), as long as the tool meets their needs at the end of the day. Ideally without confusing them or wasting their time. Keeping this in mind is good therapy for everyone involved in the process, when the technical problems get severe. Can't draw a perfect right angle or pyramid onscreen? Maybe it doesn't matter, if no one using it will notice you aren't precise, or you're wasting your energy trying to get the algorithm just right.
  11. Sometimes, while hacking in the middle of the night, an engineer discovers a road block with the planned implementation, and the proposed design and schedule are now at risk. Your test of a good process, of good team players, and probably of good design management is how this gets addressed. Sometimes an engineer comes up with a brilliant solution to a hard problem, maybe one you didn't even know you had, and your design should evolve for this case as well. The same goes for the designer's latenight insight on a cocktail napkin.
  12. Make sure the design and usability deadlines and standards are team goals, not individual goals. Otherwise your design specs won't be consensus documents, but busywork documents.


    Team Culture
  13. If you want design to be a serious concern, it requires institutional support as a group effort. It must be a part of the accepted software process and team process, and good designers and good team players should be sought out and rewarded for team performance. One cowboy coder or antisocial team member can ruin an entire product, either by implementation or by throwing the team off the path of Righteous Work and into Wasting Time on Foolishness. One extra debate or schedule slip due to poor teamwork could mean one less cool feature or critical usability fix at the 11th hour.
  14. If your design team only chases people down for violations of the company standards or the "look and feel" guidelines, but doesn't help you design the product interface, they are either being wasted or aren't good designers; and your products are on the whole probably poorly designed, unless you explicitly hire engineers who are talented UI designers and do the real work for you. (There may be mitigating circumstances, but the impact on the product is likely the same. Upsteam of implementation is where the most important design input is required.)
  15. Good product design can't occur without true respect for multi-disciplinary and varied perspectives on problems. Experts should both listen and be listened to.

    Hiring
  16. If your good designers spend time worrying about what the engineers are inventing and how to cope with it, you have a culture problem. The designers are either too busy and not rewarded for being innovative (a common problem); or the team processes are broken and there's no effective collaboration occurring. If the designers and the engineers can't have interesting conversations because they just can't get along, you're not hiring to create teams that work well together and will create more than the sum of their parts. If you want one or the other role to innovate but not both, don't hire good designers or don't hire engineers who want to build great stuff. Both types of people are expensive and hard to hire.
  17. Good design is partly just hard work on details, so hire detail-oriented people. But hire big picture people as well, to help stimulate and challenge them and everyone else. Be sure those big picture people can be relevant or state their case well, in situations where they make brilliant deviations from the group norm. (But remember in a culture where management doesn't recognize brilliance and/or isn't willing to take unpopular risks, this just doesn't matter, so in that case you should avoid hiring people who might have ideas that deviate from the middle road.)
  18. When you hire designers (whether engineers or artists), you should test design aptitude and experience (with multiple judges), communication ability, and ability to take questioning and return cogent responses. Because design is in part a talent and a capacity, you can't hire well if you don't have the right judges on the committee who can recognize this. Unfortunately, the same goes for day-to-day design decisions in group meetings: the good stuff may not get recognized in a democracy by numbers.

    Creativity
  19. A lot of design thought and work happens in forms you never see as deliverables. This doesn't mean it's not work and it's not taking time.
  20. Creativity must be fed, just as technical skills must be maintained and developed. Good product design requires feeding with interesting problems, exposure to other products, professional and product conferences, downtime to play, and communication with colleagues and researchers who are doing creative things that might inspire. But don't forget the downtime, required by all creative acts.