Making Blenders for the Blind is Like Making Software for Normal People

Brad Abrams recently posted tips he has for someone interviewing for a Program Manager position at Microsoft. In his post he references different questions and situations he likes to put candidates through. One section titled Design and Bahh Questions got me thinking not so much about the interview process, but how I might design a blender for a blind person. That train of thought caused me to jump tracks to designing software.

A BlenderFirst, let me describe some thoughts I had on my new blender. First I would reduce the number of buttons to control speed. I can see fine with my glasses or contacts, but I think I rarely use more than 3 buttons; Stop, Fast and Slow. The other 50 or so are really just a waste of plastic to me. Ok, so that last statement is an over simplification, but serves a point. But reducing the choices allows me to utilize larger buttons. Larger buttons serve two purposes, easier to touch and more room for Braille. Despite the photo to the right, I would make sure the buttons were also 'old school', meaning they were buttons and not membranes. I am sure the tactile nature of membrane buttons is nice, but if you cant see the keyboard, that is very frustrating. Get up tonight, keep the kitchen lights off and make a milk shake and see what I am talking about.

The next feature I would certainly implement is some sort of locking mechanism for the top that must be secure before any of the blend buttons would actually start the blender. Remember the user cannot see if the top has been secured or not and we don't want milkshake spewing all over the kitchen or worse yet a finger getting accidentally caught. I tried to think about some sort of audible feedback as to the blended state, but I think even I rely more on the sound of the blender to let me know when everything is good an liquefied!

So what does this have to do with designing software you ask? Quite a bit. I think most developers have above average computer IQs and problem solving skills. So we tend to have a higher success rate when learning how to successfully use software. But I know from personal experience there are still many web sites and software applications that I struggle learning how to use. Seriously if I cannot solve my problem or at least get a sense I can solve my problem in a few minutes of launching an application, without reading a manual, then I am on to the next solution. I hear the term discoverability mentioned a lot, which means a user can easily discover how to use an application and naturally discover more advanced features without having to try too hard.

Think about how much more this is the case for a normal person? I call this the Mom Factor (yes mom I am talking about you again). My mom is what I would consider to be pretty autonomous when it comes to using a computer, but she still calls me from time to time, asking how to do things. But there are many mothers, sisters, aunts, uncles, brothers, friends (do dads really call their sons for help, not sure about that one) out there that routinely call their geeks (that would probably be you) for help.

I have built hundreds of sites in the last decade, all in .NET since the summer of 2001. Back then I was in my first year of running my own thing and really starting to watch users learn to administer and interact with my web sites. I started learning a lot, mostly that normal folks don't get it. I wont go into gory details today, but just because you or I just know what to enter in an input field does not mean a real user will. We must hold their hands.

Back to my blender, I would reduce the number of buttons and make the remaining buttons larger. That exact same principle can be seen on many modern web sites. You see large buttons, large input fields and reduced forms. Most modern sites make registration as simple as an E-Mail and Password. Then once you are registered you can add other information, etc. The registration form is a good example of these very principles.

Tumblr Registration

Another rule I learned early on is never assume anything, even if a field is clearly labeled. So I have learned to add input masks, tooltips and strict validation rules. All of these measures are placed on the client, or the browser, to guide users to the correct input. Hence, why I would force our blind user to close the lid before they could engage the motor. We have to validate data, on the client, in the middle and sometimes even in the data store. The data we work with has to have some sort of expected integrity. Users will enter the most unexpected stuff. I never thought the requirement for a date a few years back would mean 'Summer' would be entered by the user. So sometimes you have to clarify even what the most obvious requirement actually means.

We have to do this because we want users of our application to just know how to use our software. Microsoft says they just want developers to 'Fall into the Pit of Success', and this has to ring true with the software we ultimately create.

Driving User Input

A few years ago I wrote a book review about Why Software Sucks by David Platt. The premise of the book, is as software developers we know how to build great applications from a functional perspective, but we suck at making it usable by normal people. It is a book I highly recommend all software development related professionals read.

Why Software SucksWhen the book was first released I think the modern concepts of AJAX were really starting to emerge. AJAX has segued into user experience (UX, see there we go, being true geeks and creating another acronym). This is why developing modern software is not as simple as just dropping controls on a form, compile, test and ship anymore. The UI layer is a very complicated matter that we have to consider when developing any application. This is why I think code generation is so important. Platt points out that we can build fantastic backend logic to do all sorts of logical decision making for us, but we have not yet translated that energy to the front of the application, where the normal person lives.

To me the whole essence in WPF and Silverlight application development center not around the markup used to create the UX, but in the creative nature REQUIRED to build WPF and Silverlight applications. These modern UX requirements are not lost on AJAX sites as well. Just look at all the UX related plugins available for jQuery alone.

I have gotten interested in researching UX design patterns lately. Mostly these sites are a collection of common design elements we see all the time and give them a name. While they typically do not tell us how to create the effects, they are good references to see what is being used so you can begin to apply the principles to your sites.

So as you work on your applications think about how you are going to make a blender for the blind, or really do your best to think like your user. And think hard at the worst user scenario you can and plan for that. Make your application as much an extension of your user's thought processes as you can.

Share This Article With Your Friends!