Following the Web Directions South UX conference in Melbourne, we interviewed Robert Hoekman Jr in an email, the interaction designer and author on his presentation — “The essential elements of great Web application design”.

If we make the application too simple is there a risk the user will get bored of it?

You don’t get bored with the hammer, you get bored with the hammering.

Web applications are tools. They enable people to perform activities, get things done, organise information, and so on. As long as the need exists to perform these activities, the need for the Web app will persist as well. And since we’re all busy, frantic people who are constantly inundated by the business of our lives, we appreciate simple solutions that enable us to do what we need to do in a quick and effective manner.

I doubt that many people have wished for a more complicated hammer. And despite that so many of us make purchasing decisions based on feature lists, we really don’t end up using more of a particular than we need. The average cell phone, for example, comes loaded with features, and many people never even tap into half of what it can do. In the end, we use only what we need to use.

If a hammer is all you need, a hammer is what you’ll use. And every time you use the hammer, you’ll appreciate how simple it was to get the job done.

What are some of the most important Web usability issues to consider?

I wish it was as easy as writing a list, but in reality, the most important issues to consider all relate to whether or not we’re communicating the right things to our users.

Our sites and applications communicate things to users all the time. Our job is to ensure we’re communicating the right information, the right cues about how something works, and so on. Regardless of whether you’re working on a drag-and-drop interaction or a registration form, the key to a good design is making sure the user will have the information and clues she needs to succeed with the design.

What is the biggest challenge of designing usable Web applications?

Sadly, the biggest challenge seems to be getting buy-in and support for design. As a consultant, I don’t encounter this problem much — when companies come to me, they’ve already decided they need design work — but I’ve experienced this often with in-house positions, and it’s the number one thing I’m asked about by the community.

Every situation is different, and each person struggling to get buy-in for design has to navigate the internal politics in a way that’s appropriate for that organisation, but there are a few things I’ve seen work well in a myriad of circumstances.

First, focus on the quick wins. Anything you can do to improve a design without impeding on a current project schedule is great, whether this means making form labels more understandable, adding instructive elements to a design, stripping some things out of a page to simplify its message, or something else. And these tiny changes often have a huge impact on the success of the design.

After you do this for a bit, teams often start to notice that your improvements have had an impact — they’ve decreased customer support calls, made development easier, maybe even brought a few smiles to some users’ faces. Once they notice, you start to get a bit more leverage, so you can shoot for some bigger changes, more time for research prior to a project, and so on. And when those improvements get noticed, you get even more leverage, in a sort of positive feedback loop. Of course, this is assuming you’ve actually made improvements!

The key is to find ways to track your successes so you can point to them later. This might mean running some customer surveys or tracking metrics or something else. But as long as you can prove that you’ve had a positive impact, you’ll build up the trust you need to take it even further.

Another important thing you can do is explain all your decisions. Whenever you make a design recommendation, describe to the developer and such on the project why you made them. Explain the rationale behind your task flows, and the psychology or usability research that’s been done that indicates your decision is a good one. Over time, your team will start thinking of these things on their own and coming up with better designs in the first place, so you don’t have to field the same questions over and over.

This can all take a great deal of time and patience, but if you can find the strength to persist, it will pay off in the long run and you’ll see your entire development culture start to shift.

How do we make the learning process seamless, so the user doesn’t feel overwhelmed with information?

First, we need to simplify our designs so that only the most essential elements exist. This keeps the scope of the application in check right out of the gate, so that you don’t inundate users with things they don’t need. From there, we need to ensure that each interaction, each task flow, is clear and understandable — not in terms of how your company thinks or how the system is built, but in a user’s terms.

For example, a company that divides cleanly into four major departments or functions will often end up with a site that is divided according to that structure, but this isn’t necessarily how someone coming to the site for the first time will understand the task at hand. The better path is to ensure that the pathways to information and such throughout the site support a user’s mental model of what the site is and what they need to do instead of forcing them to understand some internal structure or hierarchy.

On a more practical level, instructive elements can help quite a bit as well. A short line of instructive text, placed immediately next to the element to which it relates, can be the perfect solution. You can also create short screencasts to explain new concepts and interactions, provide inline tips, or any number of things to make sure that each design element is understandable.

When we use mental models do we run the risk of users interpreting them differently?

Definitely. But very often, you’ll find there are overwhelming trends within each culture, or across cultures, that will tell you which mental models to support and why they work.

One classic example is the act of deleting a file from your desktop. Back in the early days, we used DOS prompts and such to delete files, where we’d type in a command and essentially tell our hard drive that these certain bits of it can be overwritten with new information. This is an “implementation model”, which is a design that reflects the underlying system instead of a user’s mental model.

Since then, a mental model design has replaced the old DOS prompt. Now, we click a file, drag it over to a trash can icon, drop it there, and listen for that lovely little crunching sound that tells us the file has disappeared. This works because we have a mental model from the real world that has persisted for a very long time — that to get rid of trash, we toss it into a trash can. Simply translating this mental model to operating system design resulted in a very simple task that’s easy to understand. We don’t have to know what’s actually going on with the system — we just need to perform this action we already understand.

Mental model designs can certainly be misinterpreted, but most of the time, as long as you create a design that supports the way an actual human being thinks, you’ll find success with it.