Since I wrote my article “Mobile Inline Form Validation” for UXmatters back in 2012, I have very rarely used any of those patterns in my own work. Recently, when I created a pattern library for mobile applications for a big, multinational, corporate client, I didn’t include any of those tips. Since the publication of that article, I have identified and begun to follow a few principles that are I hope more user centric.
Don’t See Users As the Source of Errors
If you design systems, you are familiar with constraints. For example, it is hard to add new fields to a database; mobile networks sometimes provide poor connectivity or have slow performance or high latency. Typically, system design takes such constraints—and, of course, costs—into account in determining what a team can build. Read More
Many articles have been written on what is probably the single most ubiquitous interface element within Web applications today: the form. Forms justifiably get a lot of attention because their design is critical to successfully gathering input from users. Registration forms are the gatekeepers to community membership. Checkout forms are how eCommerce vendors close deals. But what goes in must eventually come out, and the information users provide to Web applications often makes its way back to users in the form of tabular data.
After forms, data tables are likely the next most ubiquitous interface element designers create when constructing Web applications. Users often need to add, edit, delete, search for, and browse through lists of people, places, or things within Web applications. As a result, the design of tables plays a crucial role in such an application’s overall usefulness and usability. But just like the design of forms, there’s more than one way to design tabular data.
In a previous Communication Design column, “So the Necessary May Speak,” I discussed how to reduce the number of both visual design and content elements within a table to the absolute minimum necessary for effective communication. So, I won’t repeat myself here. Instead, I’ll focus on interface design solutions that enable users to find their way through large data sets. Read More
“These are my principles; if you don’t like them, I have others.”—Groucho Marx
For a long time, I’ve been an advocate of creating standards, guidelines, and patterns as a way of achieving design consistency within a large organization. While these do offer significant benefits, they also introduce a number of problems into the design process.
Some Problems with Design Standards
First, standards can provide a false sense of expertise in design. Calling something a standard, by its very nature, seems to imply that a great deal of research, thought, and experimentation has gone into its creation. It is likely that the proper stakeholders and experts have approved it. So designing something in a way that differs from a standard sets the designer against the people who set the standard and the weight of the work that they have done. No mean feat. Particularly for people who are new to an organization or junior designers, it can be easier to keep their head down and avoid challenging a safe option. In some organizations, particularly those that outsource a lot of design work, a reliance on standards can also lead to stakeholders using the standards to design solutions themselves, bypassing the UX design team. Read More