All software manipulates information or data in some way, and to be able to design a user interface for a product, you need to understand the information that the product will present and manipulate, and how this information is structured.
Many types of projects don’t have particularly strict requirements, and in these projects, a top-down approach to design works well: The user interface designer sketches out designs for how the application should look and work, and from these designs, the technical architects and developers proceed to figure out the data structures needed to support it. Games would be the best example of products that can be designed with this approach.
On the other hand, imagine you’ve been hired to design the user interface for an income tax preparation software package. You can’t just make up whatever you want out of thin air like a game designer could — there are strict requirements on what data you must let the user enter! And so as a user interface designer working in such a project, you would have flexibility in terms of how you would design the look-and-feel of the application, and you would decide how to break up all the information the user must enter into different screens or forms. You would then design the layout and behavior of each of those screens or forms. But you would be constrained to include specific fields like “Taxable Income from Employment” on those forms, and if you didn’t, your application would not be able to calculate the correct tax amounts and would essentially violate the law. Your product would not be certified for sale by the taxation authority.
So for highly structured, data-driven systems with strict requirements, design tends to follow more of a bottom-up approach. The structure of the relevant data needs to be determined before the user interface can be designed, because the user interface is centered around presenting that data, and you need to know what that data is before you can design a screen to show it. (However, don’t interpret this to mean that a perfect and complete understanding of the structure of the data must be finished before user interface design can begin; in reality, both tend to change and co-evolve together over the course of a typical project.)
In most business system projects, a domain model or data model is created to describe what pieces of data need to be known and managed by the system, and how those pieces of data are interrelated.
- A domain model is a high-level, technology-neutral description of relevant general concepts and entities in the application’s domain; for example, banking software deals with the domain of banking, and so accounts, interest, deposits, withdrawals, loans, credit cards, and fees are examples of things in that domain.
- A data model is a more specific description of all of the relevant entities, attributes, and relationships that the software must manage, usually at enough detail to enable the model to be translated into software.
In a typical project team, the domain model and/or data model are usually created by one or more business analysts or requirements engineers, often with the help of Subject Matter Experts (SMEs) who are experts in the particular application domain. In other smaller teams, though, roles may be more fluid, and one person — perhaps someone with the title “product manager” — may be responsible for both discovering and documenting the data model and designing the user interface.
This is not a book on data modelling or requirements engineering, but to be an effective user experience designer in most types of projects, you need to be able to at least read and understand a data model, if not create one yourself. Therefore, it’s worthwhile taking a look at an example of a data model.
There are various ways to present data models, and visual notation systems are popular (though one need not necessarily use visual diagrams to document a data model).
A long-standing visual diagramming system is the Entity-Relationship Diagram (ERD), which has traditionally been popular for applications that store their data in a relational database.
While ERDs are still very common, the Unified Modelling Language (UML) is now considered the de-facto standard visual modelling language for software developers. UML consists of 14 types of diagrams. One of these, the UML Class Diagram, is similar to the Entity-Relationship Diagram, but has additional features that make it more expressive for representing real-world situations. In the next post, we’ll take a look at an example of a basic UML Class Diagram, and we’ll see how such a data model can aid you in designing an effective user interface for your product.
