I thought I’d write about the design process at SPSS, since it seems to be somewhat unusual in software shops.
Generally, as Alan Cooper has lamented, programmers design the products. At SPSS there was a separate department responsible for design. “Design” here means functionality plus UI. They would write design documents specifying every screen and dialog, every error message, every command and what they did, every statistical procedure and how it worked. (As preparation for this, they would decide on the functionality required, talk to users, and check out the competition.)
These would be reviewed in meetings, normally attended by all the stakeholders: sales, marketing, development, statistics, QA, documentation, tech support. The designer led the meeting, and the best ones were good at keeping the meeting on track. Meetings lasted no more than two hours (after that, people get bliffy); it it took longer another one was scheduled.
Anyone could criticize the design, and did. However, there was a rule that the meeting shouldn’t fix designs, the designers should. After an issue was raised the designers would go back and rework that part of the design. Trying to design a feature in a meeting produces endless discussion and wastes most attendees’ time.
Most of the designers were smart and of course were experts in the product line, and the process normally worked well. The weak spot was if anyone wasn’t really paying attention– people who hadn’t read the document ahead of time, or had little to say, or for whatever reason hadn’t bought into the product. On the other hand, they didn’t have much of a leg to stand on if they didn’t like the product once it came out.
The designer continued to work closely with the development team, keeping the design up to date, helping to solve problems as they came up, doing usability tests, and participating in bug triage sessions.
Why would you do this? Well, there are several advantages.
- It’s a huge benefit to QA and doc writers, who know what the product is supposed to do long before they get any releases.
- Designers can make sure different products are consistent, and as specialists they can produce better, easier UIs than programmers (who like arcane incantations).
- It formalizes the functionality– which helps keep your manager or the CEO from rushing in a month before ship and trying to slip in a new feature.
- A good design document won’t just say what the program does, but why. This helps avoid mistakes later, and educates everyone about what the product means to the end user.
Does it add time to the development process? It does take time, though the bulk of the work can be done while the dev team is finishing the last release, and designless products (as Frederick Brooks explained decades ago) end up late anyway.
For a tiny software shop, it may seem like a luxury– though I worked on a product at SPSS for years that had 4 to 6 programmers, and there was enough design work to have a full time designer.
A much larger firm may have a much more elaborate design process; an advantage of the SPSS system is that it’s really not that complex. The essential deliverable was a single design document; sometime there’d be a functional spec first. When we had time, the developers would produce a internal design doc as well. No one was drowning in paper.