Getting from a concept to something that is codeable is rarely straightforward. What starts off as a simple "what if it did..?" or "why can't it..?" can quickly turn into lengthy discussions as new features struggle to get defined. The knock on effect on both the existing functionality and the user experience can become difficult to comprehend, and what seems simple to one person is anything but to another. It is typically the role of a business analyst to smooth this path and to reach a solution that is agreed and accepted by all, whilst (crucially) taking as little time as possible from business users and developers.
It's a platitude, but none the less true for it, that a picture can paint a thousand words, and thus help everyone come to a common understanding more quickly. For this reason visual prototyping has been a guiding principle for many since the days of RAD, but the supporting tools have not always been that supportive. At the most basic, hand drawn sketches, brown paper and post-its can all play their part, but quickly become difficult to maintain and struggle to communicate subtitles in the behaviour of non-trivial user journeys. At their most complex, prototypes can require coding skills to create them (which can be counter productive when developer time is scarce) and can end up suffering from looking too much like the finished product, prompting users to say "great, I want it tomorrow", or getting embroiled in unnecessarily premature conversations about fonts, labels and layout.
Since starting at Black Pepper a month ago, I've become immersed in defining the next wave of features that we want to implement within Companion. This has required the rapid creation of dozens of screen mock-ups (far more than I have done in a long time) alongside stories and acceptance criteria. And with lots of ideas flying around, it has been particularly important to ensure that there has been a clear and easily understood record of the evolving requirements at all times. Not always easy, especially when learning a new system.
Thankfully, I was introduced to Balsamiq (www.balsamiq.com) soon after joining, and it has quickly become my new best friend. Without requiring any technical skills, Balsamiq allows you to quickly construct and change screen mockups, convey ideas and explore requirements. This has helped to get stories defined, agreed and estimated quickly, whilst keeping everyone on the same page.
Why Is It So Great?
- It's cheap and easy to use - anyone can be up and running in minutes
- It allows the information content of each screen to be considered alongside the stories and acceptance criteria
- The results look pleasingly like a pencil drawn sketch, and don't pretend to be anything more
- ...but it looks enough like a screen to allow the user experience to be considered early on
- It's not possible to change the font, even if you wanted to, which helps keep the conversation at the right level and stops you getting bogged down in detailed UI design
- Diagrams can be easily exported to .png files, and attached to stories in Jira
- The team like the diagrams
Invariably more detailed UI behaviour emerges during development, but that is exactly as it should be - being agile is about getting the right level of detail at the right stage of the process, and only producing documentation that is useful. And by those criteria Balsamiq is here to stay.