The best way to fix software problems
The natural enemy of any software project is warped communication. To minimize damage all agile software development methods use short cycles and close interaction with the user. Over the year I learned (partly the hard way) that what users say hardly correlates with what user do. So the final verification usually happens during the User Acceptance Tests (UAT). The problem here: the project is mostly concluded when UAT commences and conflict between users and developers are guaranteed. I yet have to encounter a specification that wouldn't allow for explosive ambiguity (or is so detailed, that when implemented is 100% not what users actually need (memento bene: need not want).
Ideally users should be able to test software before any code is actually written. This is usually accomplished using prototyping tools. The catch: to get reasonable result the prototypes take almost as long to build as the real product. But there is a solution. Do this:
- Use an open process to gather requirements. IdeaJam is great to collect and vet ideas from a broad basis of users. You only need to be careful not to run into the say/do or want/need trap.
- Create low-fidelity prototypes. Paper is a good start, but hard to distribute. Balsamiq Mockups or Denim are suitable tools. Denim is good to visualize links between screens and flows, while Balsamiq Mockups shine when it comes to UI creation. In a perfect world Balsamiq would release an add-on for IdeaJam (wink wink)
- Develop Effective Use Cases to define the interaction users want to complete with the system. (Use Cases have Pattern too).
- Test the screens!
- Test the screens: Let users interact with the mockups (you want to print them then) using Paper Prototyping (you want to read the book. or its newer cousin). The interaction reveals missing or complicated steps. If you find a missing item you can fix it in 3 seconds using a pen. Nothing beats that. It is great fun.