A vendor’s internal organization often determines usability

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.

It isn’t about the features, it’s about the design

The iPad continues to provoke a whole load of interesting discussions about the fundamentals of computing and of course that causes us to reflect on our ELN on other platforms, not just the iPad.

I’m intrigued how using an iPad causes me to think differently about user experience, and perhaps raise my expectations of what is a possible and indeed necessary.

I was reminded of this post on the ACM talking about “Why Features Don’t Matter Anymore” from 2006, where Andreas Pfeiffer talks about “the age of user experience”. He gives 10 rules about user experience:

  1. More features isn’t better, it’s worse.
  2. You can’t make things easier by adding to them.
  3. Confusion is the ultimate deal-breaker.
  4. Style matters.
  5. Only features that provide a good user experience will be used.
  6. Any feature that requires learning will only be adopted by a small fraction of users.
  7. Unused features are not only useless, they can slow you down and diminish ease of use.
  8. Users do not want to think about technology: what really counts is what it does for them.
  9. Forget about the killer feature. Welcome to the age of the killer user-experience.
  10. Less is difficult, that’s why less is more

We’ve just had one of our regular consultations with an Information Architect (IA) and even though we’ve attempted to keep PatentSafe as clean as possible, the results were enlightening. A fresh pair of eyes asking “Why are you bothering the user with that?” is always enlightening (and humbling!).

More features, especially when shoved in the user’s face, do not make for a better user experience. The user experience is one of the most important factors in the ability of any ELN project to deliver the return on investment it promised to stakeholders. That ability to deliver a return is a key aspect of any project’s success.

Interestingly we get two different reactions from customers when they look at our PatentSafe ELN.

  • In the sales process we often get asked “Is that it?” in a rather disappointed tone when we’ve demonstrated the product – of course it isn’t but we don’t overwhelm people with features in the Demo – we talk about the things relevant to to their business problem. PatentSafe is designed such that you don’t have to wrap your head around everything to understand the positive impact PatentSafe can have on your life.
  • Later when training, we get the same “Is that it?” but in a much happier way. Yes, with 15 minutes training and very little disruption to your existing workflow you can stop having to cut and stick, and move to a completely electronic world with all the benefits that brings.

One small anecdote might serve: We periodically survey our customers and one of the questions is “How long does it take to train your users”. One large pharma customer responded (slightly tongue in cheek I guess)

“45 minutes. 15 minutes to show them the system, and then another 30 minutes to convince them they already know everything they need to know”

Just because a product is powerful and can deliver a great ROI doesn’t mean it has to be complex. In fact, that’s the whole point of good design… I can’t claim we’re perfect but a good dose of Information Architecture really helps.

(most IAs work freelance – we are lucky to have worked with Karen Roles of Nidbe since we’ve started, and would highly recommend her to anyone. She delivers the sometimes painful medicine with a distinct charm… and you know it is doing you good)

Fascinating segment from Steve Jobs on go-to-market

Fascinating segment from Steve Jobs at the D8 conference about innovation and Go-To-Market strategies.

This is a really important point – you can have innovation, but if you can’t figure out a way to present it in a way that people will adopt and pay for it, there’s no way you can ever take that innovation out of the lab.

We have plenty of ideas kicking around, but it isn’t just about the technology. One of the reasons our PatentSafe ELN has the form and features it does is that we seem to have the sweet spot in terms of something we can sell to people, they can install, deploy and ultimately pay for. I’ve seen so many fellow ELN vendors come up with cool products (often received by much enthusiasm by self-styled industry watchers) which fail the “Can people actually buy & deploy this thing” test. You see plenty of marketing buzz, a couple of pilot deployments, and then it all goes quiet.

Having a good product isn’t just about feature count, it is about creating something that your customers can buy, they can install, and live with. Turns out that writing software is the easy part, creating a product people can buy and use after the marketing hype has died down is a lot more interesting.

Marc Benioff on the iPad and Cloud 2.0 – I wonder about ELNs

Interesting perspective on TechCrunch by Marc Benioff (of Salesforce fame) on the iPad and the Cloud:

The future of our industry now looks totally different than the past. It looks like a sheet of paper, and it’s called the iPad. It’s not about typing or clicking; it’s about touching. It’s not about text, or even animation, it’s about video. It’s not about a local disk, or even a desktop, it’s about the cloud. It’s not about pulling information; it’s about push. It’s not about repurposing old software, it’s about writing everything from scratch (because you want to take advantage of the awesome potential of the new computers and the new cloud—and because you have to reach this pinnacle). Finally, the industry is fun again.

It’ll be interesting to see what the iPad and devices inspired by it do for the world of ELNs. Clearly Marc’s got a very cloud-centric perspective but the success of Salesforce.com (which he launched when Enterprise software was very much a 3-teir world client/server affair) does mean he’s worth listening to.