Recommendations from UI Testing 1

Based on the first round of UI testing and the report prepared by our usability expert, a number of suggested improvements were put forward for the data downloader.  Actually, the report prepared by David was very useful.  The report did a number of things that made it easy to discuss issues with the development team and identify the potential solution.  In particular, a UI testing report should:

  • Rank the reported issues  High, Medium and Low, you can decide to rank within these categories if you wish
  • provide an annotated screenshot
  • add supporting text description
  • suggest a solution, perhaps with a mock-up or link to another site that demonstrates the solution
  • report “bugs” separately
  • dont go overboard – listing 100 faults is not helpful. (note – hopefully you shouldn’t have 100+ faults if you have understood the who, what, why of the design brief)

The USeD development team were able to sit around a table and come up with a course of action on each one of the issues raised in the UI Expert report.  How long did this take? 60 minutes. That’s all, honest.  A well presented document that described each issue clearly meant the developer could concentrate on the technical solution and judge whether a solution could be implemented in the development time available. Only a couple of issues got “parked”.  This was generally to do with the capabilities of the software and hardware and implications of server load.

A list of the changes that we will make to the interface is given at the end of this post.  So what have we learnt from this initial review?

  1. the usability expert liked the new site so that was good.
  2. He pointed out several things that are now blindingly obvious to the USeD team.
  3. We now appreciate the benefits of presenting UI results clearly, they shape the development of the UI.
  4. We know that we can make the UI better and easier to interact with.
  5. We know what we have to focus on for version 2

We now have about 2 weeks of development time before we roll out Version 2 for some more UI testing.

Points that will be investigated for Version 2

  1. Remove “do one of the following”
  2. Isolate pan as it is a separate function to draw or select
  3. On load, products list should be collapsed
  4. Add better headers to products list such as “Product” “Allowance”
  5. Make it more obvious when an allowance is exceeded, perhaps red text or strike thru text.
  6. Add a modal box if a user selects a product for which the allowance has been exceeded
  7. Remove lock/unlock icon
  8. Make info button change on hover
  9. Add info about which data product is being viewed in the map window.
  10. Remove Scale-bar
  11. Define area buttons need cleaned up – perhaps 1 define button that opens a pop-up
  12. Add more descriptive help to functions like define Square in the popups
  13. Popup and modal boxes should close when “GO” is pressed
  14. In basket, change preview and trash can to change colour on hover
  15. Give the “Add to Basket” button more prominence.
  16. Greyed out buttons too subtle (add to basket/define circle(not functioning at present))
  17. Are arrows the best symbol to use for clickable function submit buttons?
  18. Possible to get lost in map, have a reset view (planned but functionality issues prevented it going out in Version 1)

Aspects that we could not take forward with an explination of why.

  • Change the product names to be more meaningful and descriptive – the OS are insistent that their products should described by the correct products name. We also agree that this is sensible as many products are quite similar in some ways, but different in others. Conveying this in 2-50 characters would be difficult.  Further, using the official product name means that Digimap users are using the correct terms that are used in the public and private sectors.
  • When a user selects a product, update the map window to show the product. This would make a stronger visual link between what users see and what they eventually get. The preview windows are too small to be very useful. – This would be possible for some products but initiating this to say preview Mastermap or other large scale mapping products.  The load on the server to facilitate this could potentially be considerable and impact on the speed of the service. In addition, maps would not render in a readable format on screen if users tried to view large areas of large scale maps.

Link to the usability report prepared by Usability Expert

Comments are closed.