By the time they call in the GUI Police, it’s usually too late already.
You know the scenario, right? The development team (which, in a typical small business scenario does not include any user interaction designers) works like crazy on a web application for about a year. They implement cutting-edge functionality, over-the-top back-end contraption . . . and all kinds of “interesting” ways to use the same button for three different purposes, dependent upon the step in the workflow process, the same button will do three different things. Cool, eh?
Companies that focus on usability, human factors and graphical user interface design
Good web application GUI examples
Around that time, they show the web application to the boss, who in turn wants the Customer Support department to see it, too. Oh, and then Sales & Marketing join in as well. That’s usually about the time they realize that the end user documentation is missing.
If you’ve ever been in a situation like that, you probably know what’s coming. As soon as real people see the web application, they are going to have questions. By golly, you know, even though everything was supposed to be intuitive and straightforward, the people over 30 just don’t seem to get it. They can’t figure out that right-clicking that one icon (looks like a tin can but means ARCHIVE) is what you’re supposed to do on that one web apge. And so forth and so on.
After that, one very embarrassed development manager has a meeting with the boss. In a very diplomatic manner, the boss tells the development manager that “the end user experience needs to be finetuned a little bit.” The development manager then starts looking around for someone (anyone, really) who can define usability and hopes to have all the problems solved by the time he finds such a person. Perhaps even post an ominous message to that effect on craigslist, eh?
Back in the real world, the web application completion date gets delayed. Developers and their managers begin to stress out. Graphic designers get hired to fix something that nobody can explain in actual words; usually, somebody will just point at the web application and say something along the lines of, “We need this to work better.”
Inevitably, the budget for the project needs an increase, because now things need to get fixed and revised and re-tested. If everything goes well, somebody comes in and advises the team on usability, end user eye movement, GUI standards and a variety of issues involving white space, targetability of graphical user interface elements that need to be clicked, consistent fonts and a global color scheme.
However, the likelihood that the average small business in the United States ends up hiring someone like HFI, EffectiveUI or Cynergy Systems seems very small — due to the seemingly high cost associated with such companies. (This is by no means a scientific assessment, but based on the number of HR related web applications I have seen, tested and experienced, this conclusion seems very reasonable.)
Most lilkely, somebody in the organization knows someone who has done something like this before — or worse, they know someone who knows someone else. As a result, a lot of usability and graphical user interface work goes to people who don’t necessarily do such work on a regular basis. Quite frequently, this kind of work goes to ad agencies and creative design outfits who know all about dazzle but very little about the particular workflow of the web application.
In the end, usability and graphical user interface work gets a bad rap. Developers tend to get even more frustrated, because the decision to make all buttons blue (instead of gray) does not seem to solve the actual problems the boss wanted to have fixed. Even worse, some smooth-talking creative designers find a way of justifying almost everything with the right spin on it, and when the boss buys into a series of such arguments, the development team feels as though all hope is lost.
So much for the typical bad-case scenario. Now let’s take a look at the flip side of that coin.
If you end up hiring someone who knows what their doing and/or has done similar work before, chances are, the developers will have to re-program some of their work, but the reasons for doing so will actually be the solutions to the overarching problems.
For example, the boss, the manager and even the developers might agree that the order process is cumbersome and confusing. So they look ath the one web page on which all of this takes place. They have some very precise questions for the usability and GUI expert, and they want to know whether the buttons should be in a different color, and would it make more sense to have the drop-down on the left side or on the right?
OK, that’s good. People are thinking about stuff. Unfortunately, in some cases it makes absolutely no sense to focus on such a small aspect of the entire web application. Chances are — and this is not meant to be offensive rather eye-opening — if we’re worried about this sort of thing, we’ve overlooked something else entirely.
Don’t get me wrong. I’m not writing this with an “ I KNOW IT ALL AND YOU KNOW NOTHING” attitude. For many years, I used to struggle with myopia in the sense that isolated web page (or software screen) designs were thrown at me out of context. Only when I stepped back and worked through the way the entire web application (or desktop software program) was supposed to work did I have an AHA moment. Most of the time. Not always.
And, yes, I still struggle through the GUI design and usability process. Things change all the time, and we certainly don’t ever want to take anything for granted. And you never really want to be in charge of your own web application (doing the usability, the GUi design and the programming all by yourself) — that only leads to system-centric design.
In a nutshell, realizing that it takes an outsider to take on those tasks is a critical first step to getting things right (or at least righter). And by outsider, I’m not necessarily talking about someone from a third party. It can absolutely be a staff member, just not the same staff member who has other stakes in the development process (or is the lead developer of the project).
Such findings have been previously documented by others who deal exclusively with software design and usability. If my memory seves me correctly, even well renown usability expert Jakob Nielsen has brought up this particular point on a number of occasions. So have others, but let’s move on.
If we allow an outsider to take a look at the workflow — and what we’re ultimately attempting to allow the end user to accomplish — we will often find that, in an effort to get things done and do those things in an awesome way, we ended up over-developing. I’m not saying we developed too much, but I am suggesting that we typically end up being too clever for our own good.
For example, consider a simple HR process in which the web application needs to evaluate an employee’s performance. In this web application, you get to evaluate a number of performance factors (such as timeliness, accuracy, working with others, etc.). You rate an employee on each individual performance factor, and to get from one factor to another, you click the NEXT button.
Then, when all factors have been evaluated, and there is no more next factor to advance to, you get to mark the perfromance evaluation as “ready to meet in person.” Only now, the clever web application has switched the NEXT button ot a MARK AS READY button. Sure, it might actually be a totally different button (from a developer’s point of view), but as far as the end user can tell, the buttons are in the same place, look the same and only one of them shows up at a time — so why wouldn’t it be the same button?
Now presume the meeting process is over and the performance evaluation can be taken to the next level. Yes, you are right: The developers changed the button again, and now it states COMPLETE. Pretty clever, eh?
The point of this little example is that sometimes, as developers who are knee-deep involved and invested in the development, worrying about deadlines and project milestones, we can easily get too close to the technicalities and the functionality of a web application. All the pressures tend to make us forget that not everybody is as computer-savvy as we are, and somebody else might just not get it (especially if the end user only uses the web application a couple of times per year).
To follow up on the scenario I mentioned above, it was actually much more helpful (to the end users) to break up the factor evaluation part of the performance measurement web applciation into three separate web pages (or screens):
1) evaluation
2) meeting follow-up
3) completion
More work? Yes, if you consider that an existing web page had to be broken apart into three separate web pages. More satisfaction? Yes, even the boss was happy and found such an approach reasonable. Could this have been avoided? Absolutely.
Once again, the point here is not to belittle web application developers who have to call in the GUI Police after the fact. The point is to convince stakeholders to consider usability and graphical user interface design up front.
- Web application developers, web designers and UI experts need to be involved in the design and development process from the start. (Let’s add a member from the Documentation team as well.)
- That’s not to say that they should be cross-trained in each others’ areas of expertise; it simply means that they need to run things by each other and work through the planning phases together.
- As ridiculous as this may sound to some people in 2009, do some user-centered research upfront. Even if your product enters Version 5, you might want to do a reality check and find out whether the old, etsablished workflow still applies or not. If possible, invite a few local clients to meet with you and talk about the ways in which their people use the web application. Call it a focus group and get the boss to pay for drinks and donuts.
- Even more ridiculous, come up with paper prototypes, demonstrating the workflow and the key elements for each step of the way. Draw these by hand until you’ve run them by a few people. Use tape to add (removable and/or flippable) dialog boxes. Hang them up on a wall or a white board, and walk through each step with the product developer or a subject matter expert. Meet in groups or with one individual at a time — as long as you find out what works, what is expected and what might be unacceptable.
- Don’t ever be afraid to ask questions and try out new things. If you’re not sure about something, ask now. If you’re going to commit a blunder, do it now during the planning and prototyping phase. It will be cheap and easy to rectify. (Committing those blunders during beta testing is going to cost money and cause a lot of stress, but that’s still better than fixing and revising things after the official product release.)
While most of my observations and explanations may come across as common sense to most of you, dear readers, I am hopeful that there is a hidden nugget in all of this for one or two of you.
Perhaps I might be forgiven for being somewhat opinionated about how to be n effective usability & GUI expert by listing a few additional ideas about being (or becoming) a usability & GUI person in general.
- Pay attention to the way software works — or deosn’t. If something works well for you (for example, Microsoft Word 2003), try and figure out why it works. If something annoys you (for example, Microsoft Word 2007), on the other hand, try and figure out what it is that makes it hard to get things done. Most of all, nurture ideas about what you could do to improve the software.
- Read, read and read. Get your hands on books by software design evangelists, usability experts, human factors experts and others who are engaged in making software and web appications work for the rest of the world. A few names that come to mind are JoAnne Hackos, Robert M. Gagne, Jakob Nielsen, Alan Cooper, Kathy Baxter, Donald A. Norman, Deborah J. Mayhew, Patrick W. Jordan, etc.
- If you don’t have easy access to any of their books, look up their web sites, search for podcasts, find their videos on YouTube or just simply go to town on Google.
- Find a mentor. If any usability or GUI authorities hold workshops, seminars or give keynote addresses near you, attend. It’s also a good idea to put your ear to the ground and find out who’s considered an expert in those fields in your geographical area. Perhaps you could meet up with one of them for occasional chats or visits. Perhaps they would allow you to call them (or send them e-mail messages) once a month to find out what’s new in the field?
- Volunteer to be involved in product reviews at work. Or jump at every opportunity to conduct usability testing (with actual end users) or participate in reviews. You may not always have a lot to bring to the table (especially if there already is a designated usability expert), but you will certainly learn something new every time you engage.
- Take screenshots of good examples. Start your own collection on flickr or photobucket. Give credit where credit is due, and cite the sources (you will be glad you did when you finally find a good use for one of the design approaches you saw several months ago).
- Participate in GUI and usability discussion on message boards, join relevant groups on LinkedIn and on Facebook. Listen to others. Follow the links of those people who seem to have the best comments. Ask for follow-up clarifications if somebody mentions something you’ve never heard of.
- If at all possible, get yoru hands wet on a few freelance projects (if you are a full-time employee somewhere else). Don’t worry about the money (yet). Try and find someone locally, so that you can meet with them in person to discuss their GUI & usability needs.
- Unless you know how to use Photoshop (or something just like it), find a graphic designer with whom you could collaborate. Ten out of nine times [sic] it is important to show your clients what you mean by mocking up a few examples.
- Most of all, don’t have an IT’S MY WAY OR THE HIGHWAY attitude. Almost every situation involving GUI design & usability advice requires some sort of compromise. Perhaps it’s impractical to re-program the entire web application, and you need to make do with what you have. You’re going to have to negotiate with project managers, developers and CEOs. Be tactful. Make your point, support it with evidence from current studies and tests, and then present two or three solutions in such a manner that your clients can gracefully decline Option A but still feel in control when accepting Option B or C.
Companies that focus on usability, human factors and graphical user interface design
Links to various companies that promote usability, human factors, graphical user interface design and such in a good way:
Human Factors International
Jakob Nielsen’s Web Site
Nielsen Norman Group
EffectiveUI
TandemSEVEN
UX Roast
Cynergy Systems, Inc.
Web application with good GUI implementations, resources, etc.
Examples of web sites and web applications that have implemented best practices in terms of usability, human factors, graphical user interface design and such.
WebAppers
User Interface Resource Center
Envato
Yahoo Design Pattern Library for GUI Developers
AudioJungle
Good.is
Digitalmash
CollabFinder
Postbox
RedBrick Health
GUI Design & Prototyping Tools
