Good design

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
– C. A. R. Hoare

Apple have taken their user interface design for iPods and made it into an art form. It’s a benchmark that all UIs should seek to reach. But in my experience there are a number of factors most Business Analysts need to overcome;

  • Design can be influenced by current business processes and systems, and the opportunity approach problems differently is not taken.
  • In a lot of the projects I have worked on the BAs and developers are not normally respected for their design abilities, it is not something that appears on a CV.
  • Few software builds are completely brand new, there is often reuse of code or design, therefore designs are an evolution not a revolution. Design may be compromised.
  • The underlying business process is not optimised, therefore the system has to handle avoidable¬†process exceptions, or performs¬†unnecessary¬†steps.
  • Large projects may suffer from a lack consistent design across modules due to different development teams having different design styles, or calling similar pieces of data by different names.
  • At a management level functionality is often valued more highly than usability. This is probably because one is more measurable than the other.

So those are some of the issues, what’s the solution? The following approaches will address some of the more pressing issues.

There needs to be some tangible benefits to improving design, something measurable. Some examples may be:

  • Software adoption rates: is everyone using the system, all of the time.
  • Productivity: time spent hunting around the system for data, or too many touch points.
  • User mistakes attributable to design issue. e.g. Two fields with similar names, complex user configurable rules, etc.

Identifying and measuring tangible costs of poor design puts usability on an equal footing with functionality.

The project team needs an accepted measurement of the User Experience. We need to create some guidelines. Some typical ones maybe:

  • Maximum numbers of key presses to achieve a task.
  • Maximum numbers of drill downs to find data.
  • Ensure there is no duplication of any processes, or data.

Everyone from the Business Analyst, to the developers, to the testers then have a measure to work to.

Once the project is under way there needs to be user involvement in testing the design, as early as possible in the project life cycle.

  • User groups, these need to be actual day to day users
  • Storyboard the most common scenarios with users, it is possible to use the business requirements and examples of real items of work that need to be processed.
  • Prototype the system or create mock ups, walkthrough the storyboards and get user feedback on how they would see themselves using the system etc.

The sort of things I am looking for are as follows: is the system intuitive? does the system flow? and does it flow in a way compatible with the business process?

Posted in Design, Tools & Techniques Tagged with: