DESIGNING FOR VARIOUS STATES
When designing a page that draws set of results from collection of data (i.e. database) the screen layout should be designed to serve three core states of the application; Normal, Empty, and Error.
Normal State: is when system returns expected results.
Normal state can be further broken down into two sub-states:
– Overflow State: when the system returns too much results.
– Minimal State: when the system returns too little.
Empty State: when system returns no results
Error State: when system returns unexpected results due to system or user error.
Intended layout, aesthetics, and usability of the page must be preserved throughout all of the possible states described.
USING REALISTIC DATA SETS / CONTENT
It is important to use sample data sets or content that closely resemble the real-world scenario. Pages designed around irrelevant placeholders result in compromised usability, awkward layout and aesthetics when asked to handle production data.
Following are some points to consider:
– Maximum or minimum character length
– Anticipated amount of text (for heading or paragraph)
– Date or text format
– Amount of data (If only one or two lines are returned, does the table get lost on the page? Does it get buried under heading or text? Is the information still legible?)
DESIGNING FOR THE FUTURE
Applications designed for the web, by nature, change and evolve over time. Designers need to think about not only how the UI works now but how it would expand, get modified and improved over time. User interfaces and interactions need to be flexible enough to easily accommodate the future. This applies to design as a whole or individual feature.
Modifications may include:
– Addition of features, links or menu items
– Deletion of features, links or menu items
– Modified interaction
– New mesh-ups with third-party applications
The design should also take into account the possibility of customization, variations, or internationalization that caters to various clients, markets or cultures.
An application should not only be able to support multiple languages, but layout and usability should also be maintained across various internationalizations. Consider the impact on the length of text in button labels, table headings, columns and other areas where real estate may be limited.
Designers should also be aware of the cultural differences. For example, different colors or shapes may carry different connotations in other parts of the world.
There are other socially sensitive issues that design need to take into account. For example, what radio button should be placed first? Male or Female? Which country should be listed first in the dropdown? Should it be strictly alphabetical or context sensitive? Things like this may have significant impact depending on the culture and the context.
PERSUASIVE DESIGN – GUIDING THE USER
Using hints to provide a clear obvious path is preferred over alerts, error messages, or lengthy instructions. In addition to concise textual hints, design elements such as white space, positioning, size, texture or color can contribute to guide a user complete the task successfully.
The best error message is no message at all.
As much as we try to avoid more interactions than absolutely necessary, there are scenarios where the app inevitably needs to require significant involvement from a user – whether in the form of additional clicks or additional pages. This may be due to technical limitations, business requirement, or other non-controllable external forces.
Users of business apps look to results. They are not looking to get entertained or be amused. Often in a business application, a reasonable amount of repetitiveness can be tolerated in return for improved accuracy and/or security. In a business app, when saving a click and accuracy collide, accuracy should always trump.
Focus on Activity-Centered Design
Sometimes overly emphasized user-centered design can lead to haphazard results and chaos. It shouldn’t be the goal of the design to cater to every possible user limitations or problems. Design must focus on the goal of the user. An activity-centered design focuses on the scope and the context of the utility in question rather than on the users’ ability (or inability), preferences or behavior.
This approach – by guiding or nudging the user in the right direction – is far more likely to yield desired results than correcting the user when errors are made.
There is no single perfect solution or design for a given problem. Designing web application for the most part is about making appropriate compromises at the right time and in the right places. This is especially true for enterprise applications with complex business requirements and constraints.
Advancements in front-end technology in recent years have made many ‘cool’ features on the web possible. We are in an era where if you can imagine it, there is always a technology or techniques that can make it happen. As a result, many are currently being used and also abused. The question now should be not ‘is this technologically possible?” (because, most likely the answer would be Yes) but “is this cool feature really necessary?”
Cool features or behaviors shouldn’t be used for coolness sake or just because it can be done. Like everything else on the web app it should be used only when it’s absolutely necessary for the task at hand.
Providing alternatives is a good idea but only if the alternative offers something new or different that the first method did not. Creating more than one way of achieving the same thing only creates confusion and noise unless they both present unique benefits that couldn’t be shared. For example, an application may provide options to view set of images and data vertically in a list or as a thumbnail grid. Each option provides benefit that the other cannot offer. List view may include more details while grid view shows more results at a glance. Both of which are difficult to achieve in a single solution. Therefore, proving an alternative view option is rightly justifiable.