It might be obvious and redundant to say this, but the usability of a software product or a website depends on its user interface. There’s probably a bunch of code and usually a database underneath, but the user doesn’t really see any of that – the user only sees and works with the user interface.
So what is a user interface? Once way to look at it is “presentation + behavior”.
The presentation is the content or the data, and the controls the user can click on or otherwise activate, tied together with a visual design.
The behavior is how the user interface reacts and what the application or website does when you operate the controls.
Underlying both is a conceptual model that includes a model of the business domain – what concepts or entities are involved, what they’re named, and how they’re interrelated.
Behavior is important, but for now, let’s first concentrate on the presentation side. Putting some effort into getting the presentation right is important for a lot of reasons.
The visual design – the layout, colors, fonts, and so on – differentiates your application or website from others, and is one of the first things your users will notice when they encounter your product. What will their first impression be? If your product looks professional, it will inspire more trust and confidence than a product that looks sloppy. Is your application or website an inviting and friendly place to be?
Beyond first impressions, the presentation gives the user the means to discover and activate the functionality that your application or website provides. Functions might be activated by picking menu entries, clicking on icons in a toolbar, typing commands, directly manipulating visual objects (e.g., painting on a canvas in a paint program, or moving a spaceship in a game), or other means.
Making the possible actions and functions visible is important when users are learning how to use your application. For example, users looking for a search function will be able to find it if there is an appropriate icon in a toolbar, or a text box labelled “Search”, whereas if a search has to be activated by pressing Ctrl-F7, users will probably never discover it. But there are trade-offs to consider. Putting hundreds of confusing icons in several rows of toolbars might be overwhelming. Placing them in cascading pull-down menus might clean up the clutter, and would give the user textual descriptions instead of icons to decipher – but it will take longer to navigate through menus to activate a function. And power users might want that keyboard shortcut so that they don’t have to reach for the mouse. We’ll talk about these kinds of trade-offs in later posts.
Additionally, the layout of screens or pages can explicitly or implicitly communicate relationships between entities. For example, grouping things together in one area of the page suggests that they are related. And if there’s a header over a block of text or a set of fields, you’d expect the all the things under that header to relate to what the header says. Careful attention to layout can make understanding your application easier, while sloppy and inconsistent layouts can confuse users.
In the next few posts, we’ll start exploring the basics of visual design and page layout.