Thinking outside the CRUD box »
FERDY CHRISTANT - JUN 15, 2009 (08:42:11 PM)
Many companies that do custom application development do not have dedicated designers, front-end engineers, interaction designers, or whatever they are called today. Instead, these companies rely on application developers to develop a user interface for an application. This situation can have consequences on the usability of the resulting user interface. A common pattern that I personally have been stuck in for years is the CRUD pattern:
CRUD stands for Create Read Update Delete, the basic interactions you need on pretty much any entity you introduce into your application. In your architecture CRUD is likely to appear in multiple layers. If you have a users table, you may have CRUD operations in stored procedures, a Data Access Layer (DAL) and a Business Layer (BL) to carry out the basic CRUD operations on that user table.
The design mistake occurs when you extend that pattern to the user interface. Let's reuse the users table example. If you extend the CRUD model to the UI, you'd probably create a page that enlists users along with links to view, edit or delete an individual user. You'll create a page to view a user and one to edit a user. You'll name your fields and labels to the names used in your actual table. You may even generate the whole UI since it leans so much on the database model.
Through a few simple, subtle examples I want to show you how it can be beneficial to usability to think outside this CRUD model for user interfaces. Here they are:
1. Think about your labels
Labels are what you call your links, buttons, menu options, form labels, etc. They are crucial for usability. A subtle example here is a form label. If we had a users table containing a description field how would you call the form label on the edit form?
The CRUD way is to call it "description", just like the field name. A better label would be "describe yourself", which is actionable, or "About me" which makes more sense to a user. The difference seems subtle, but if you apply this to all labels throughout your design, your UI usability will improve. Form labels are only a start, navigation and button labels are of equal importance.
2. Tables do not equal screens
Stuck in the CRUD-model, we tend to make a one to one relationship between a table and a screen. We build an edit form containing all fields of the user table that should be editable. This does not always make sense, as users tend to think task-oriented, not storage-oriented. This example from Digg.com illustrates my point:
Notice how Digg.com provides different options to edit different parts that evolve around a user. Each option has a dedicated screen that is optimized for the task. Although it is likely that Digg stores all of this stuff in a single user profile table, this is not reflected into their UI. There's even a possibility to do an inline edit of a single field (the avatar icon). Clearly, this part of the Digg UI is task oriented, the way it is stored in the database is abstracted away. In a CRUD approach, we'd have a single user profile edit form containing all fields.
3. Users do not think in fields. They think in natural language.
In CRUD design mode, we visualize data (in read mode) similar to the way we store it. Tabular, data-like, as if we're looking directly at the content of a record or table. Users, however, are not database administrators and not everybody is an accountant. Sometimes natural language is better. Consider this example from Digg (again) where some key fields of the user profile are used to form a natural sentence:
Not only does this take up much less screen space, it also reads a lot more fluently. It is as if I as a user do not have to connect the dots to learn about this great person, the application has already translated it to language I can understand. The application turned data into information. They're not the same.
Surely my examples do not apply in every situation, but they are just examples. I hope this article inspired you to understand the subtle difference between a database-inspired UI (CRUD) and a user-inspired UI (tasks, natural language). It takes practice to think outside the CRUD box, but I feel the result is rewarding. We as developers may not all be professional usability experts, but it never hurts to develop a change in mindset.
Please do rate/comment below.