I have an IA (information architecture) colleague Matt, who often lament that the BA screen concepts he reviews do not reflect user needs nor reflect how the users would like to interact with the system, particularly in a web environment. Matt comments that many of the documented screen concepts are designed to “talk” the developers through the use cases rather than the reflect the business user experience.
I have recently been involved in a project where it was difficult to articulate the needs of users in the requirements specifications, because the users did not really know what they wanted. They only knew what they didn’t want - their current system, which was described as “clunky”. The system was built in software that was no longer supported by the organisation and over a number of years, they had developed a number of manual “work arounds” of this system. The users were hard to engage as they had little time to discuss and review requirements and wanted the system asap. Sound familiar?
So I started with the basics and looked at their current processes, asked how they would like to work in the future, had meetings with various stakeholders and sought their advice on what inputs and outputs were required. The business area had little time to discuss the requirements and even less time to review formal documentation (that was technical in nature in order to inform the development team). Therefore I decided that to ensure I had got the specifications right, I would build a working prototype to show them how the system may look, feel and be used rather than using screen concepts. My aim was to involve the system users in defining the requirements to ensure I got the business needs right.
This concept worked well. This particular prototype was built in Axure, however there are a number of such software applications available that will do the same job. The application was able to simulate a working system and show the users how they would interact with the system rather than just showing them a series screen concepts. The application used allowed users to experiment and make comments about its useability and suitability to their needs. It was very much a communication tool to engage the user and ensure they were involved in the decision making process. The prototyping will be an iterative process to refine the requirements and should result in better definition of business requirements and eventually a better system.
Sweet prototyping tool - hadn’t come across that before (although I have become pretty handy with Visio for wireframes).
As you rightly say, though, prototyping with a good tool is only half way there. Theory and methodology of information design, usability, and accessibility, is also needed to support good ‘design’ decisions — they prompt questions like:
* scope - what information and what content is needed by the system’s users? what information support is needed to help system users? what processes can be supported and how?
* structure - what taxonomy of navigation and information is needed to easily get around? Folksonomy? Taxonomy? Both? How can they be used to create a logical and consistent flow of information?
* skeleton - what parts, widgets, banners, forms, do users need? Where can they go on the page to ensure they can be easily used? How can they be consistency applied to ensure context is maintained throughout the system?
* surface - what will the graphical elemets look like? how can they help rather than hinder?
Asking these questions differentiates a good prototype (and a good prototyper) from a poor one, regardless of whether they call themselves a BA or a User-experience designer.
M
“IA Colleagues” ???
… that would be me! *LOL*
M
Yes, Matt it is you.
M