“It should just work!”
Not a week goes by where those words don’t come of out my wife’s mouth. I look over to see that she’s either ready to chuck her smartphone across the room because her virtual keyboard stopped working, or she’s about to punch her laptop screen because the (fill in the blank) website is misbehaving.
“No, no, NO! Why doesn’t it work?! It should just work!”
A little part of me dies inside every time I hear her say it…because I’m a software developer, and I have no response for her aside from “I agree – it should just work.” As a career software designer, architect, and developer primarily focused on manufacturing software systems, I’ve created some pretty complex stuff, stuff where the team remarks, “I can’t believe that actually works”, stuff that I’m proud of. I’ve always given special attention to the user community – designing applications to work the way they work, using terms and processes they’re familiar with, and ensuring the app fits the need. But I have to admit that I’ve missed the mark a few times too. I can’t help but wonder if I’ve caused someone to yell at their computer screen. I wouldn’t bet against it.
Taking a step back and thinking about what I expect from software and how it really should just work, I narrowed in on three pretty basic questions.
- Is the design intuitive?
- Is the app effective and efficient at serving its purpose?
- Is it interesting?
Three “yeses” and you’ve got yourself a winner.
1. Is the design intuitive?
I’ve never read a user manual in my life. I’ve assembled my fair share of IKEA furniture over the years, but that doesn’t count.
If I’m not going to read manuals, I’m not going to expect my end users to either. That means the software I design has to be intuitive. To guide me, I like to imagine myself in the shoes of three different users:
- A manufacturing equipment operator I met years ago. While this type of person happens to be my typical audience, the memory of this particular woman has stuck with me for more than a decade. Her primary job was assembling connecting rods for massive diesel generator engines, and using software application was not part of her normal routine. I can remember to this day her response to us introducing her to a new shop floor system we had just installed. Her shoulders fell forward, she rolled her eyes, and in a defeated tone she sighed, “…another thing to learn…” To say that the limited exposure she had had to software of any kind had all gone very poorly would be an understatement – she had given up before we even started. I begin here, because if I can appeal to her, then I’m half way to my goal.
- My nine year old sons. I’ll [humbly] admit they’re pretty sharp, and they like all things electronic, but they have zero exposure to business and manufacturing systems of any kind (they’re nine). Some advice given to me ages ago: “design for someone with a third-grade education, then anyone will be able to figure it out.” Would they be able to do something with my software?
- My mom. I’m being kind when I say that she’s a little behind the times – she doesn’t have a personal email account or smartphone, and she doesn’t use a computer at home. If I can answer “yes” to the question, “could my mom figure out how to use this?” then I’ve done my job.
2. Is the app effective and efficient at serving its purpose?
Inefficiency drives me nuts, and that applies to software too. I want to know the quickest way to get from Point A to Point B, and don’t make me do anything along the way that I don’t absolutely have to. Software should simply serve the purpose for which it was intended – it shouldn’t get in the way or create more work for the person using it.
In his TEDx talk, “The habits of highly boring people”, Chris Suave uses the following slide to make a recommendation for how to reduce time spent on mundane tasks.
In thinking about how this example applies to software, I wouldn’t say that end users hate using the applications I create, but in many cases the software is a means to an end – so the approach of eliminating all that isn’t absolutely necessary and automating as much as possible leads to a pretty effective and efficient design.
In so many software packages, you have to go from one screen to another to another to complete one simple task. This type of interaction isn’t exactly conducive to the way people have become accustomed to getting things done. Designers have to understand the way different audiences will use the software, in order to eliminate and automate what they can, and to leave the user to focus on more important things.
3. Is it interesting?
Think of the most popular smartphone apps of the last few years – Twitter, Angry Birds, Facebook, Candy Crush, Instagram, Flappy Bird…ok, maybe not Flappy Bird. They’re simple in concept, yet interesting and visually appealing. By visually appealing, I don’t mean they knock your socks off, but your attention is drawn to the appropriate parts of the app, you’re not distracted by meaningless clutter, the colors and graphics are pleasing and not offensive – it just feels right.
We have a term for the antithesis of this, and it’s something I see all too often – we call it Angry Fruit Salad. Picture all the colors of the rainbow splattered all over the screen in seemingly random fashion –red borders, yellow buttons, blue diamond, purple horseshoes…you get the idea. A lot of time, effort, and money have been put into the psychological response to color and organization, and, as a result, the proper use of color and best layouts for certain scenarios. Leveraging these standards and recommendations and designing something to be visually appealing are not mutually exclusive!
So, if you’re a software developer, please take pity on your users and consider these simple principles in your next design session. Or, if you’re in the midst of a software selection process or looking to do something custom, think about the impact these three simple things will have on your user community and set yourself up for a win.
Jason Strawhacker is the software development team leader at Flexware Innovation, where he has been part of multidisciplinary teams designing and implementing manufacturing software systems for the past 17 years.
Team Leader, Software Development
Husband & Father. INTJ. Woodworker. Runner. I detonated a mollusk.
