Expressing the intended purpose
User Interface design is an interesting blend of art and science. Visual appeal is important, but not the end goal in most cases – and it can even detract from desired functionality.
We’ve all experienced products with great visual appeal that just don’t work for us, whether it is a sleek cell phone that feels awkward in our hand, or a stunning web site that is hard to navigate. Truly good design blends an appealing aesthetic with comfortable functionality for the user of the product – whether it is software or an espresso machine.
User interaction is the point at which software design diverges from traditional media. The only point of traditional media is to broadcast a message; the users’ only interaction is to watch and listen. In order for the message to be conveyed, the user must remain engaged (visually/aurally), so the focus of the designer often drifts from conveying the message to viewer engagement.
It is easy to recall TV advertising that missed the mark because the entertainment worked to keep the viewers attention, but failed to create a strong brand association for the advertiser. Similarly, a compelling visual design can miss the mark for software that requires user interaction.
Clearly user engagement is important, especially when the software (web site) is targeted at consumers for whom engaging content is part of the “payback” of using the software. Even so, the engagement is merely a tool – because as the “Dot-bomb” era of the late nineties hammered home: “Eyeballs” are no substitute for revenue.
So how can we avoid the trap of focusing on user engagement to the point that we lose sight of the ultimate purpose of the software? We have found that Stephen Covey’s habit #2 – “Begin with the end in mind”, although formulated to address personal effectiveness, can easily be applied to software effectiveness as well. Take a shopping cart as an example: If the goal is to present maximum advertising or cross selling before the customer becomes annoyed and leaves the site, that dictates a different visual design and input flow with more steps than an objective of completing a transaction as quickly as possible.
At Triact, we engage with clients based on that basic principle by asking leading questions at the outset and throughout the life-cycle of a project. At every point in an application where a user is provided with a visual or auditory stimulus, the design of the software should be informed by insight into what we want the user to feel, what we want them to do next, and what we want them to remember. The answers to these questions then inform our investigation of what information or cues should be presented, and how best to present them.
The actual user matters
This is pretty straightforward, at least conceptually, but becomes more difficult when the objectives of different stakeholders in a project collide. For example, much software for commercial users has been developed with the ends in mind of senior management, without significant input from the folks who will actually use the software.
I got my most valuable lessons in UI design in my first job as a software developer, because I was working for a small company, and I had to provide telephone technical support to 500+ customer users as well as designing/building/debugging the applications. Talk about an eye-opener! Business owners were buying these systems to meet their business objectives, but their staff people were the ones using the software. As I talked many of those staff people through the actual use of the software, the connection between support costs and usability of the software was hammered home in a very personal way!
Those early lessons in usability and maintainability have stuck with me and enabled me to work with all the stakeholders in a project (managers, users, developers, etc.) to arrive at designs that meet the competing demands of ultimate functionality and transactional ease of use.
Balancing multiple purposes
In order to arrive at a UI that accomplishes the ends of both Management and Staff (users), we have to ask those important goal-determining questions of both audiences, and reconcile the apparent differences. The users want UI’s to be simple and make their jobs easier – management may want certain business rules applied that tend to make user processes take longer and not be so simple. Often, the role of the software designer/architect begins with reconciling the competing objectives of those who dictate the workflows, and those who actually operate the software enacting those workflows.
Let’s take an example involving a PDA application for order picking in a warehouse. We have three different constituencies to satisfy. Management wants real-time transactions to the ERP system to ensure inventory accuracy, and they want to enforce FIFO consumption of goods. Users report they frequently arrive at a location to pick material dictated by the ERP system, and it’s not there, so they need a means of identifying and picking the same or an alternate lot from a different location – so they want simple interfaces that allow them to adapt on-the-fly to what they find in their work environment. On top of all this, the CTO in the company wants to use rich displays with on-screen (multi-field) input – using the stylus.
Can you hear the users groan? The last thing any of the warehouse users wants to deal with is a tiny plastic stylus to click on tiny fields on a screen in order to get their job done. In the abstract, the multi-field input seems like a good idea – but not to the actual users. Unfortunately, many software implementations have failed because users who find software hard to use will then find a way to not use it!
For this reason, we have championed the finger as the ultimate input device, long before Apple put the finger over the stylus for the iPhone. Below I will contrast examples of a PDA UI based on a multi-input, stylus-oriented design with a PDA UI based on a single-input, finger-oriented input paradigm.
Multi-input PDA UI
The designs below are an awkward mix of input fields, check boxes so small they require use of a stylus, and buttons that might be finger operable. The variety of input options accommodate al possible workflow choices for the operator, but when 95% of the time an operator is executing a linear flow – the presentation of complex input options increases frequency of errors.
Single-input PDA UI
In contrast, the PDA screens below follow a paradigm in which the upper portion of the screen is used exclusively to present information, the only buttons are finger-sized and at the bottom of the screen, and the only input prompt/field (if any) is at the bottom of the screen.
The same work-flow can be implemented with either UI paradigm, but the single-input model means the operator can focus their attention on the bottom of the screen and follow a linear and deterministic prompting sequence, unless they encounter an exception that requires them to refer to the information on the upper ¾ of the screen.
In the end, the client has the authority to override our recommendations, as was the case with the multi-input example above. Balancing the competing imperatives of multiple stakeholders means applying judgment regarding relative priorities and management philosophy that is best exercised by the responsible parties within the client organization. As a partner, we make sure we point out the strengths and weaknesses of different design approaches to the various stakeholders, offer our recommendation, then faithfully execute based on the decision of the client.
In contrast, the PDA screens below follow a paradigm in which the upper portion of the screen is used exclusively to present information, the only buttons are finger-sized and at the bottom of the screen, and the only input prompt/field (if any) is at the bottom of the screen. The same work-flow can be implemented with either UI paradigm, but the single-input model means the operator can focus their attention on the bottom of the screen and follow a linear and deterministic prompting sequence, unless they encounter an exception that requires them to refer to the information on the upper ¾ of the screen. In the end, the client has the authority to override our recommendations, as was the case with the multi-input example above. Balancing the competing imperatives of multiple stakeholders means applying judgment regarding relative priorities and management philosophy that is best exercised by the responsible parties within the client organization. As a partner, we make sure we point out the strengths and weaknesses of different design approaches to the various stakeholders, offer our recommendation, then faithfully execute based on the decision of the client.
Bottom line
Good design in the world of software UI’s depends on the same guiding principles used in other disciplines:
· Begin with the end in mind (for all stakeholders)
· Let form follow function (of the actual user)
· The client may not always right (in our opinion), but they are always the client
Become proficient at applying these principles to a wide variety of circumstances, and you’ll have many satisfied customers and users!
