Few (if any) scientific software vendors have the scale of companies like Apple and can poor millions of dollars into Usability testing – the market just isn’t large enough to support that, and even if we had the money I doubt we could find enough willing volunteers. Producing usable software in this market requires a somewhat different approach.
In an article on 52 weeks of UX, exploring “The Distance Between Maker and User” the following principle is espoused:
As the distance between the maker and user increases, so does the difficulty of designing a great user experience.
This is our approach to usability – we make sure the Geeks are never too far away from the end user, and we achieve this in the following fairly simple ways:
- The people responsible for writing our products support them. We don’t have a support team – the guys helping our customers are the ones who you will speak to if you have a problem or need advice. This is probably the our effective way of increasing usability because not only do the developers get swift feedback on their decisions, they have an incentive to engineer out problems at source.
- We regularly review the kinds of issues we’re getting and see if we can make them go away entirely. Sometimes this is a re-worded screen, sometimes it is removing a step or component completely. I appreciate lots of vendors do this as part of a standard quality process, although we tend to do it in fairly tight feedback loops.
- We use the product internally. Did you know that PatentSafe makes an excellent financial records system? :-). Not only does that mean we have internal customers who deliver feedback every day, but the developers (and managers!) interact with our products daily. You’d be surprised how many little tweaks come out of this, things that customers probably notice but don’t think it is worth bothering us with.
- Our Sales, Development, Admin and Management teams are all co-located in the same office space, which means there’s lots of gentle interaction and sharing of context. It is interesting how often a problem in one area can be resolved in another. There are some problems with this because the different functions have different working styles (for example sales people switch context every 10 – 30 minutes, developers every few hours) but some simple informal rules make things easier.
Every time we bring someone new on board they are surprised that we aren’t more “formally” organised, but so far this setup has really helped us. It does mean we need to check that techies also have people skills, that our admin people need to be slightly more techie, and our sales people do need some involvement in the more geeky side of the shop. However it does seem to work very well for us, as demonstrated by the short training period that new users need to get up to speed with our ELN, and also the low volume of support calls we get (which apparently is very low compared to most software vendors).
Interestingly once new employees get over the initial shock of the proximity of roles, they really enjoy the richer environment it creates.
Having a small distance between the designers and developers is something that happened when we were a small startup, but I’ve come to view it as tremendously important for our ongoing success.