The participants were divided in small groups. Each group was given pieces of Lego, varying in size and colour, and was instructed to build a chicken and create a specification.
Once the chicken was designed and its specification was put on paper, the chicken was dismantled. The Lego pieces and the newly created specification then moved on to another group. All groups were instructed to rebuild the chicken according to the specification, and when finished pass it on to another group. This time the groups were instructed to review the rebuilt chicken and compare it to its specification.
Finally all groups presented their chickens, specifications and bugs. Just like in real life, the groups had a limited time frame for each step of the process.
So how did it go? Well, we got to know each other better through fun and engaging discussions. The main conclusion was that the specification was far from sufficient; for instance, four out of five specifications didn’t specify colours at all. And of course, this led to a lot of reported bugs.
This exercise highlights the fact that the usability engineer (or anyone else in the project team, for that sake) cannot work in vacuum and write specifications, there is always room for interpretation for the recipient. In this game the groups were not allowed to communicate with the other groups – of course, this was a bit extreme. But in reality, the project team is often spread out in different locations, making face-to-face communications a rarity, and making the integration of UCD in the agile software development process even more important.
Not only did the game reflect the different stages in the software development process, but also the different disciplines (users) involved in the process. It illustrates the importance for the usability engineer to understand not only the end-user’s need, but also its colleagues’ expectations and limitations.
Specifications are needed, but they cannot replace human interaction. The true quality of the product can’t be completely evaluated before it’s been put into use, but to ensure the best possible outcome, it is important that the users of the specification are not forgotten.
In order to secure the usability of our specifications, we have as a complement to our HCI guidelines created an interactive live implementation library of our applications. With this we hope that the era of long specifications that are not read nor understood is over, and instead replaced with user-friendly specifications with supporting interactive examples, which will make it easier for the usability engineer to be a part of today´s agile software development.
This is the story of how we created a dynamic specification. How do you manage the usability of your specifications?
If you want to read more about how we ease the transition from guidelines to implementation check out my colleague Benjamin’s blog post here.