We made it reliable. What's next? Usability?

I'm working in a small development group. We are building and improving our product.

Half a year ago we couldn't think about higher characteristics, such as usability, because we had so many problems with our product. Many bugs, high technical debt, low performance and other problems kept us from being able to focus on usability.

With time we've improved our process substantially. What we've done:

• Real Agile iterations
• Continuous integration
• Testing(unit-tests, functional Smoke tests, performance)
• Code quality is 'good'
• Painless deployment process

So we are now producing stable, reliable releases. The following quote (paraphrased) describes our current situation:

first - make it work; after that, make it reliable; after that, make it usable

We are geeks, so we can't 'make' a great UI by ourselves. So what should we do? What direction can you recommend? Maybe we should hire Usability experts part-time or full-time? How can we explain the importance of Usability to our stakeholders? How do we convince them that this is useful?

From stackoverflow

• What do your users want ? They're probably the people best placed to identify requirements.

  Richard Ev : You can expect your users to tell you if a proposed UI is good or bad, but don't expect them to design a UI...

  Fedyashev Nikita : Sometimes it can be hard to get their exact thoughts about the theme..

  Brian Agnew : The point is that they may not *want* a (G)UI. The point is to find out from the users about their requirements from your product - features/bug fixes/performance etc.

  mavnn : Depending on the business model, providing what the current customers want might not be the best way to attract new custumers. After all, the existing ones have already learnt to use your ui.

• What do your Business people say will make you the most money? Do that. Maybe usability is the next thing to do, maybe more features, maybe a different product. It's not something a "geek" will necessarily be able to guess.

• I know so many geeks including myself who know usability, so one way would be learning it. Another way bringing someone in who can do UI design and usability.

  To convince them that usability is important: It's useless if you can't use it!

  I don't know what sort of product you build but you always got clients, and clients always love usable applications. This will increase sales, happy client count and decrease tech support.

• Make a UI.

  Then throw that away, and make another after you tried to use the first one. Then simplify as much as you can. Any time you can programmatically determine what the user wants from inputs, instead of multiple explicit choices, do so. Too many buttons induces paralysis.

• What does it do for your users? What do they think about the usability? Maybe it's not an ssue for them.

  Make it more valueable to your users. Deliver more business value. Help your customers getter a better return on their investment. Do this by making it do more of what they need it to do, to do it better (more accurately, more quickly, more reliably more useably), or to do it at lower cost (less infrastructure needed to run it, reduced maintenance costs because you improved reliability), more flexibly (deals with their business changes)...

  Lots of dimensions which do connect with the technical ones you refer to (usability reliabilty stability etc). But paying customers normally care about their business needs/features, not your technical ones that deliver them.

  Go talk to your users (or potential users)

• I'm in the same boat as you are - I basically live on the command line, and I'm completely out of touch with the modern UI (both web and desktop application).

  The solution for me was using a real UI developer for all my GUIs, and I just live in the back-end as it were.

  There are quite a few benefits of this arrangement:

  • You don't have to debug your own crappy UIs anymore :) that's their job, and they're better at it than you, so no worries.
  • Your code will naturally gravitate to a MVC or at least tiered API approach, which is easier to code against for all parties involved.
  • Good UI people know what questions to ask end users, and know when those users don't know what they're talking about. I certainly don't have that skill.
  • You can do what you do best, and they do what they do best, making a stronger team overall.

  The cons are obvious - you need to not only find the money for a talented UI dev, but you need to find a talented UI dev!

  Now, I can't speak for you and your company's position in your market etc etc (I also don't do buisnessspeak :) ) but if you can afford another hire, it will give back more to the team than the cost of the position. It did for me!

  Nifle : I sooo wish we would hire a UI developer.

• When analyzing the next step it really all comes down to business requirements & goals.

  What is upper management like? Are they tech-savy? Are they open to new ideas? Do they think that the current product needs adjustment, improvement, etc? Is the product still in high demand? Is the marketplace changing such that the product/service will soon be obsolete? etc. etc. etc.

  IF there are real business reasons for spending the $/time/resources then you can begin to explore product improvements. At that point consider the opinions of previous posters regarding user opinion.

• You are the ones who know and understand the product, so don't assume that just because someone else has 'usability expert' in their title that hiring them will somehow make your product usable.

  Also, don't undercut your own instincts for usability. As a programmer, you use software all the time, what products do find the most usable? Think about what you like about them and compare them to your product.

  Think about what your product does, and imagine that you are the person having to use the product and imagine how you would want it to work. Think of what a user wants to accomplish using your product, and imagine the steps they would have to go through to do it. Does it seem easy to understand what to do? Can it be done in fewer steps?

  Most importantly, talk to your customers. Find out what they found confusing or difficult to accomplish. See if they have come up with their own workarounds for using your product in ways you didn't initially picture.

  If you put as much thought, planning and effort into usability as you did into improving the reliability and deployment, you will end up with a much better product.

• My one-liner about the importance of usability:

  • What use is a reliable system that is not usable?

  If you have an existing product with existing users, then what makes you think that your current UI is not usable?

  Do you suspect that there are some minor changes you can make that will greatly improve usability or is something more revolutionary required? If the latter, then what about the needs of your existing users, will they be willing to re-learn a whole new UI?

  Edit

  A user interface can be considered "poor" for a variety of reasons...

  • It is just plain ugly / old fashioned / does not "look like a Windows application"
  • It uses metaphors or workflows which do not relate to things that the user understands or wants to do

  The first of these is relatively easy to fix, especially if you hire in a great designer. The fix would be the equivalent of redecorating your lounge and buying a new sofa and TV. Same room, different experience. Your existing users would still be able to use this application.

  Fixing the second of these gets a lot more complex and involved, and might really impact your codebase. It's hard to comment further without knowing more about your application.

  Fedyashev Nikita : Yes, we have existing users, and I'm not a big fan of revolutions. But I suppose that our UI isn't good, as it can be. Very nice point about UI re-learn for users. Thanks

• You ask, "How can we explain the importance of Usability to our stakeholders?" but I'm not sure that you yourselves get it!

  Interaction design (iD) and usability aren't things that you can tack on to an existing products when the "important" things are done. They should be there from the very first start, preferably done in small iterations with small tests and studies. I'm talking about cheap and dirty iD/usability, stuff like lo-fi prototyping, user testing with just four people, having enough stats to be able to detect user errors and such.

  If you don't to iD/usability from the start, you risk ending up with the same crappy product as your competitors and/or providing users with band aids when they need surgery.

• I think the answer is in the order of things, you say its:

  "first - make it work; after that, make it reliable; after that, make it usable"

  But the most important thing here is "make it work". Acceptance criteria for a functionality to "work" is that it is in fact - usable. If not, it will not be executed. Then it's just a block of dead code. And dead code should not be in the system in the first place.