Over the past few years, there’s been a ton of buzz word creation; “RIA”, “Web 2.0 & 3.0”, “Semantic Web”, “Social Media”, “Microblogging” “Cloud Computing”, the list goes on. The truth is that all of us in the tech industry often forget thechnology’s ultimate purpose: To improve humanity… We forget that all the software we create will ultimately touch a human being.
I’ve done it myself, created some incredibly elegant code, something that I was very proud of, but nobody in the real world cared – It was because I was caught up in solving the puzzle, mental masturbation if you will, and lost the bigger picture with an actual human being on the other side.
About 8 years ago, I realized that there was a huge gap between what people wanted in software, and what I was delivering to them. That realization challenged me to start to focusing on user interface development. I didn’t know it at the time, but this was the impetus for EffectiveUI.
Being a developer at heart, I attempted to create the blueprint for all software developers – some kind of system that we could all run our code through to ensure its usability. What I quickly learned, of course, is that this is not a technological problem; it can’t be solved with ones and zeros. I needed to remove myself from my developer shell and actually try to understand people – not easy for the bullied, introverted, geek in high school (I did have one friend, my Apple IIe ).
After 4 years of working alongside the extraordinarily talented people at EffectiveUI, I’ve come to the realization that the best we can do today to describe usable software is to list a set of subjective criteria – I know it ain’t perfect, but we’ve come to use it internally as a measurement for success on all of our engagements, and our clients seem to agree that we are giving them a leg up by focusing on these 8 criteria:
#1: Usable Software helps people accomplish goals
Yeah, no kidding! But believe it or not, if you only think about “solving the puzzle” it is very easy to forget the very people you are creating the software for. When interviewing David Armano for the UIRC, he said something that is so simple, but is a fundamental truth that is often overlooked in many software initiatives:
“[Good software] does what I want it to do. So I don’t know if that’s a complex or simple thing, I just know that it works for me. When you look at the landscape of Web applications and desktop applications, if something doesn’t work contextually, it becomes a moot point even though it might be a great technological advancement.”
All software you create must help someone accomplish something. Some of the ways to ensure this on a project is to go out and interview the target customers of the application. Watch them in their daily routine – understand the other software they find utility from (even if that software is not related to your initiative) . Even more important, understand their pain in using that software – their biggest pain is your biggest opportunity…
#2: Usable Software is responsive and performs
Most interactive agencies make design the first class citizen and force development to take second chair. This is a classic recipe for failure. If a creative director is responsible for final requirements, I guarantee the application will fail. If technology is an afterthought, performance will suffer. Your customers will not tolerate poor performing software – It’s like owning a Porche that gets 1 mile per gallon and goes only 15 miles per hour, it may look pretty sitting in your driveway, but trying to drive it to the grocery store would be an exercise in futility.
In order to ensure software performs, you have to make creative compromises. You must ensure fluid collaboration between design and development … John Lasseter @ Pixar put it best:
“design challenges technology technology inspires design, and the process feeds itself”
If you can accomplish this culture in your software development process, magic will happen.
#3: Usable Software is brand consistent and trustworthy
This is almost the flip argument to #2… The ying to the Yang if you will. Having a technical architect responsible for final requirements is just as disastrous as having a creative director drive them. What you will wind up with is software this very logical, and is completely understood by technologists. But what happens if your end customer is someone more real, like your mom, or a child, or someone in China? I recently did an interview with BTQ that touches on this subject – Ensuring brand consistency is giving your customers the trust that this software was written by professionals. People will not put their data into a system that looks like it was built 5 years ago, they will not trust their data is secure.
Trust in a system is the most commonly overlooked, or bypassed. However, it is also the one thing that can have the largest impact on user adoption. In a study conducted by Nielsen Research, Trust was the #1 reason why people did not buy on the web – 5 times the #2 reason “no need for the product or service” – think about that for a second… People were five times more likely to walk away from an offer due to the lack trust in the site than from the lack of need for the product.
Trust is the primary reason why social networking is quickly becoming the marketing channel of choice for many organizations – they have realized that having one’s friend recommend you is better than any marketing collateral – people trust their friends and influencers more than they trust any marketing text on your website.
However, there are other ways to establish trust – if your software looks professional, modern, secure, and brand consistent, people will trust it.
#4: Usable Software provides valuable feedback
Have you ever clicked on a button in an application or on a website and literally nothing happens? So you click on it again, because you’re not sure if you actually clicked it, and still nothing… So you keep clicking until you get the app to crash. This is because the application is not providing you the feedback that “it heard you” – it is necessary, in some cases, to make people wait for processes to complete before moving on the the next step. But you must make sure the application provides feedback behind every user interaction. Otherwise they will be confused, disorientated, or just plain angry.
Simple advice here – make sure everything a user is to interact with provides some feedback for that interaction.
#5: Usable Software behaves with consistency
Large, enterprise systems typically suffer from consistency issues. Small, utility applications usually have one to 5 uses at the most and it is easy for a single individual to design consistent controls. But once your team gets larger than 4 to 5 people, it is really easy for similar components of the software to act in totally inconsistent ways. Salesforce has many examples where things behave one way under “contacts” and a completely different way under “settings” – it makes the learning curve very long.
We tackle consistency issues with something called an Interaction Model – think of it as a style guide but for controls and transitions. Apple has probably one of the best examples of documentation to counter-act the issues with inconsistent software behaviors called the Apple Human Interface Guidelines
#6: Usable Software behaves in a familiar way
All software is innovative. Otherwise, why are you writing it? You are trying to solve a problem that has never been solved before or in a way that has never been attempted. Innovation is critical – but you have to balance that innovation with familiarity. Some people believe that they can substitute a “familiar” interface with an “intuitive” one. They believe that they can create controls and systems that are new and innovative, but also intuitive. My favorite quote on this is often attributed to Bruce Ediger in 1995:
“The only, truly ‘intuitive’ interface is the human nipple. After that it’s all learned.”
Later, bruce refined the statement with:
“There is no intuitive interface, not even the nipple. It’s all learned.”
I find it interesting when people discuss the iPhone – everyone thinks it is so intuitive and easy. The truth is that Apple has invested heavily in making the phone familiar, not intuitive. Their advertisements are showing someone using the phone (just a finger and the phone) – They have made a very complex user interactions like multi-touch, gestures and automatic orientation very easy.
To prove my point, try handing an iPhone to someone who’s never seen the commercials – I tried this once with my mom – she was TOTALLY lost.
So – how do you make something that is familiar? i refer back to the point in #1 : user interviews and testing. Go to where your customers are, and watch them in their environment, using other software. In those circumstances where you must invent a new control, or want to try some innovative transitions and interactions – prototype them and get them in front of the users quickly to make sure you are developing something that is usable.
#7: Usable Software is efficient
Now, I’m going to contradict myself. Rapid user testing and instant familiarity is not always the best way to provide a true usability. Quite often companies are measuring usability in the first 15 minutes of someone’s interaction with a product. They are taking an eCommerace “conversion” mentality for crafting their software. What if you are creating software that is meant for people to work in 8 hours a day, 7 days a week – like patient record data entry, billing system management, contact management, or customer service ticketing? If you take the “first 15 minute” approach to usability testing, you are certainly going to make software that is way too simple to accomplish more sophisticated and lengthy workflows; you are going to make software that is very inefficient.
To make software efficient, you need to make sure you do not “launch and forget” – Know that you are going to get a lot of things right, and some things wrong in every release – plan for measuring user behavior as a part of your post-launch process and integrate course corrections into your multi-release software project plans.
#8: Usable Software is elegant and engaging
This is by far the most subjective of all the criteria, and probably the most important to get right. This is where the art meets the science. You will hear people say – “this just does not feel right” — I know, very valuable and actionable feedback — How do project plan for elegance and engagement when you are never sure when you are going to achieve it? How do you mitigate the risk of projects going wildly out of budget when you are dealing with very subjective things? Frankly, its very tough. This is why most companies that engage in any software endeavor try to diminish the importance of engagement – Last year, we were up against a very large (50,000 consultant) SI in an RFP – we lost the deal because the SI was able to convince the client that “since this is a internal application, usability is not that important anyhow” — at least they had integrity to not lie about their ability to make usable software …
This is by far the hardest thing to message to our clients – “why focus on elegance and engagement?” Will Tschumy gave a presentation , “Why Design Matters”, where he asked a simple , but brilliant, series of questions:
” What was the first MP3 player in the US Market?”
Diamond Rio PMP300, Introduced November 1998
“So why do most of us have these?”
Apple iPod – Introduced October, 2001
Will then makes a very interesting observation:
Why Didn’t the Rio Win? It had:
- better battery life
- more storage
- more formats
- first to market by 2 years
- had more features
He suggests it is because it balanced the wrong constraints – I think that’s just a different way of saying that the folks that introduced the Rio did not effectively value “elegant and engaging”
More to come
This year we are writing a book with O’Reilly that explains how to take these 8 criteria and put them into action. The book, tentatively titled “EffectiveUI, the Process for Creating Breakthrough Software”, will walk through example project deliverables and techniques that will help project teams execute against these 8 criteria —
Like this:
Like Loading...
Anthony's Blog 