• Functional requirements are the features your product will have, in terms of the functions, actions, and behavior it will support. For example, some functional requirements for a word processor would be that it support bold and italic type, that it allow documents to be printed, and that it allows images to be embedded in documents.

• Non-functional requirements are performance or quality constraints that are general or “cross-cutting” in nature. Non-functional requirements address areas such as performance, security, stability, capacity, and scalability. For example, an e-commerce website might be required to serve 100,000 users concurrently and provide a response time of 2.0 seconds or less.

The scope of your product and project is defined by the set of requirements that need to be implemented. Without careful management, additional wishes and demands will continually be added to the project’s scope. This phenomenon, known as scope creep, will threaten your ability to deliver on schedule.

Requirements should be stated in concrete, measurable terms whenever possible. For example, rather than stating that “the product must be easy to learn”, which is subjective and unprovable, you might consider a phrasing that lends itself to objective testing, such as “95 percent of users will be able to successfully process a standard passport application after the two-day training session”.

Some requirements are “definitional”: they result from, and form part of, your definition of what the purpose and market positioning of your product is. Other requirements need to be elicited from your users and other stakeholders.

Because usability problems tend to emerge when key issues like navigation, workflow, and transactions haven’t been thought all the way through, it is worthwhile spending time on thinking about these issues and explicitly designing and evaluating solutions.

Not everything can or should be decided at the very beginning; preliminary decisions will often have to be made which can then be changed or refined as the project goes on. However, some fundamental things are very hard to change once product development is in full swing, and so these things — what we might call the architectural design — should receive special attention early on in the project.

It is possible to describe an interaction concept in a formal specification document, and for large teams building large products, this can be a reasonable approach for recording and communicating the design to team members. But creating a formal deliverable is not the point, and nor is it the only way to document and communicate design decisions. Writing a specification is good if it forces the team to think through and decide on key issues, but a formal document can be difficult to write because many things, like the visual design, are very difficult to specify completely and accurately in writing.

A more agile approach that tends to be more successful is prototyping, in combination with some minimal, agile documentation. Prototyping can be a very effective way of trying out different design ideas and getting feedback through peer reviews and usability testing. A prototype alone cannot capture and communicate all of the design decisions and rationale, though, so lightweight written records can be used to supplement it.

What kinds of issues make up the interaction concept?

• A choice of one or more interaction styles
• The basics of the information architecture, which may include:
• Data model
• Behavioral model
• Glossary of preferred names
• Navigation and wayfinding
• Search and indexing
• A framework for interactions and workflow
• A transaction and persistence concept
• A visual design framework (essentially, the product-wide look-and-feel)

We’ll examine each of these in upcoming blog posts.

One traditional approach to designing and building software products was the waterfall model, where requirements are first gathered and written up in specifications documents. These are then handed off to designers, who create designs and write design specifications. These are then handed off to developers, who build the product. The product is finally handed off to testers, who verify that the product matches the specifications.

This sounds fine in theory — it’s a very logical, rational decomposition — but for large, complex products, this approach never really seems to work very efficiently. For complex projects, it’s never possible for analysts and designers and programmers to get everything correct and complete on the first try, and so waterfall projects inevitably tend to break down into a chaotic scene of documents being passed back and forth between groups for correction. And since software projects span months or years, it’s very frequent that the requirements will change during the course of the project, meaning that by the time the product is finally built and released, it may no longer actually meet the needs of the users and stakeholders.

An effective way of bringing some order to this chaos is to recognize that complex analysis, design, and development work is never done completely or correctly on the first attempt; it takes many iterations of reviewing, revising, and testing to get it right.

An iterative approach to design and construction breaks the project into many short, structured cycles of work. In each pass around the cycle — each iteration — the work products get better and better and more complete. An advantage to this approach is that you get a basic functioning version of the product available for testing very early on in the project, and this early product can be used to discuss and further refine requirements with the project stakeholders.

Attempts to illustrate an iteration of the design cycle usually end up looking something like this:

The Design Cycle

This diagram is unsatisfying, though: it suggests that the activities are separate and take place sequentially, and this is not always the case. There is often constant, fluid switching between the different activities, and team members will usually be working on different activities simultaneously in parallel.

In addition, the nature of different products can enable various different design approaches:

• For products with formal processes and very specific externally-imposed requirements, such as a tax calculator, requirements analysis and specification usually have to be figured out fairly thoroughly before detailed design can proceed.
• On the other end of the spectrum, products such as games have no real requirements — just about anything goes, design-wise — and so requirements analysis virtually disappears.
• Most products fit somewhere in the middle, and requirements analysis and design proceed together in a tightly meshed fashion. Sometimes requirements aren’t formally recorded at all, and instead the design is simply continually adjusted to match the new learnings about how the product should work. So in these cases, the Understand requirements and Design activities merge together.

And for products that lend themselves to rapid prototyping, often no formal design documentation is ever recorded. The prototype is the representation of the design, and so the Design and Build activities merge together.

The User-Centered Design approach recommends that you involve users in requirements gathering, and in the usability testing and evaluation of designs, prototypes, and the actual product.

In other blog posts, we’ll take a closer look at the activities in the design cycle. We’ll examine requirements analysis and validation, the process of design, prototyping, evaluating designs and prototypes, and conducting usability testing.

The user interface framework will provide user interface controls or “widgets” — buttons, text fields, drop-down boxes, and so on. Knowing what set of controls you have to work with and what they look like is obviously important for design and prototyping. For the purposes of visual design, it is also good to know the degree to which the look-and-feel of the controls can be adjusted and customized, and what mechanisms are used for managing the page layout.

The technology framework that will be used for implementing the user interface can impose constraints on your designs. In particular, different web application frameworks can vary widely in their capabilities. For instance, some frameworks offer the ability to present modal popup dialogs, while others do not; older frameworks may not support partial page refreshes, requiring entire pages to be reloaded to show new data. The Oracle ADF framework, as of the current writing, does not offer any means for disabling or hiding options in pull-down menus.

If the framework chosen for your product has limitations, you will need to be aware of them and find ways to work around them — but these workarounds can often impact usability. If the problems are serious enough, you may need to reconsider the choice of framework, and it’s better to discover and decide this early on in the project, rather than later, after most of the product has already been built. Thus getting a good understanding the framework and its capabilities and limitations is a critical early step in user interface design.

In some projects, UX designers may have some input into which user interface framework will be chosen for the project. But in most projects, technical architects choose the technology stack — the set of frameworks that will be used to develop the software, including the user interface layer — based on technical considerations, cost analyses, political factors, and sometimes, personal preference. The UX designer, who is typically brought in at a later stage in the project, is then left to design interfaces that are implementable with the chosen technology.

The choice of user interface framework should be decided upon careful consideration of the requirements, or at least the best known understanding of the requirements at the early stage of the project, and ideally a user experience designer should be involved in determining those requirements.

In a UML class diagram, we can represent entities (classes), attributes, operations, and various types of relationships between entities. Let’s understand these by examining the following simplistic UML class diagram showing part of the data model for a banking application:

The boxes represent the various entities that the product needs to know about. (When we are talking about things in the domain, we usually use the term entities, but when these entities are implemented in software, they are more frequently called classes. We’ll use the term entities here for clarity.)

An entity is an definition of what information is needed to represent a thing or a concept, or a set of similar things or concepts. Entities basically represent nouns.

In our example diagram above, the Customer class represents all of the pieces of information, or attributes, that our application needs to know about customers: their customer numbers, their first and last names, and their dates of birth. For each entity, there will usually be many concrete instances of that entity (also known as instantiations, records, or objects) known by the system, and each instance will have its own separate set of values for each attribute.

In other words, for our Customer entity, if the system knows about 500 different customers, then there will be 500 instances of the Customer entity in the system, and each of those 500 Customer instances will have its own set of values for the attributes. One Customer instance might be for a customer with a customer number of 1234567, first name John, last name Smith, and date of birth 05.05.1965. Another Customer instance might be for customer number 2345678, Alice Jones, born 07.07.1977.

In UML class diagrams, the box for an entity is divided into multiple sections:

• The top compartment contains the name of the entity, such as Customer.
• The middle compartment lists the attributes for the entity. Attributes are the fields that describe the properties of the entity. So if the entity is a noun, the attributes might be thought of as adjectives that describe the noun. For the Customer entity, the attributes are CustomerNumber, FirstName, LastName, and DateOfBirth. In domain models, usually just the attribute names are given; for data models suitable for implementation in software, the data type for each attribute is usually given as well. Here, “String” means text, “Date” means a calendar date, and so on.
• The bottom compartment of the box is optional and is frequently omitted. It lists any operations or actions that software implementations of instances of that entity can perform. These operations can be thought of as verbs that the entity, a noun, can do. Not all entities will have operations, and operations are typically listed only in data model and not in domain models. (The notation used for naming the operations usually reflects the programming language being used in the system, which is why the example diagram here includes the additional brackets and the “void” annotation.)

Relationships

Relationships between entity classes are represented with lines drawn between boxes. The UML standard uses various styles and combinations of lines and arrows to indicate different types of relationships. Let’s examine the two most common relationship types: associations and inheritance.

Association relationships

The most common type of relationship is the association, represented by a plain line linking two boxes. An association relationship means that two entity instances (objects) can be linked together. In our example diagram above, Customer instances can be linked with Address instances and Account instances.

The numbers alongside the relationship lines indicate what is called the cardinality of the relationship. In the sample diagram, the association between Customer and Address is what is called a 1-to-1 relationship, and this means that every Customer instance must be linked to exactly one Address instance. In other words, a Customer cannot have more than one address, nor can a Customer exist who doesn’t have an address on file; every Customer instance must always be linked to an Address instance. And likewise, an Address instance cannot exist in the system if it is not linked to a Customer, and an Address instance can only be linked with one specific Customer. This particular model diagram doesn’t allow two customers (a husband and wife, for instance) who happen to live at the same postal address to share one Address record in the system; each Customer must have its own Address, which means there would be data duplication (two Address records holding the same postal address data) — which may have usability consequences.

The association between Customer and Account, on the other hand, is an example of what is generally called a 1-to-many relationship. There is a cardinality indicator of 1 on the one side, and the other side, the 0..* notation is shorthand for “zero or many”.

This means that the number of Account instances that a Customer can be linked to can be between “zero” and “many”. So a customer in the system might have no accounts at all, or he or she might have one account, or he or she might have two or twenty or even more accounts.

But the 1 on the other end of the association means that an Account can only belong to one Customer; two Customers cannot share an Account (at least according to this data model).

Inheritance (specialization/generalization) relationships

Another type of relationship is the inheritance relationship, drawn with a plain line with an open triangular arrowhead at one end.

If you see an inheritance relationship where the arrowhead points from, say, entity Dachshund to entity Dog, this indicates that entity Dachshund inherits the properties of Dog. Dachshund has a copy of all of the properties of Dog, but may have additional properties of its own. We can say that that Dachshund is a subclass of Dog, or we may say that Dachshund is a specialization (or a specialized type) of Dog. And if Dog had multiple subclasses, like Dachshund, BlackLab, and Poodle, then we would say Dog represents the generalization of the commonalities amongst the subclasses.

In our banking example above, there is an entity called Account, and below it, there are two entities, CheckingAccount and SavingsAccount, which are specialized types (subclasses) of Account.

Instances of the CheckingAccount entity take on all of the attributes and operations of Account, and additionally have the attributes and operations specific to CheckingAccount. So a CheckingAccount instance has the attributes AccountNumber, AccountOpenedDate, Balance, and OverdraftLimit, and can perform the operations MakeDeposit, MakeWithdrawal, and ChargeFees. Likewise, a SavingsAccount instance has the attributes AccountNumber, AccountOpenedDate, Balance, and InterestRate, and can perform the operations MakeDeposit, MakeWithdrawal, ChargeFees, and ApplyInterest.

When a customer opens a checking account at the bank, a link is made between the Customer instance and a new CheckingAccount instance. And when a customer opens a savings account, a link is made between the Customer instance and a new SavingsAccount instance. Because a Customer can have between “zero” and “many” accounts, a Customer may be linked to multiple CheckingAccounts and SavingsAccounts, or none at all.

But a Customer will never actually be linked to an instance of Account. Why? Account is what we call an abstract supertype — no instances of that type can actually be created in the system. You can only create one of the subtypes. So if a customer wants to open a new account, he or she must choose between a CheckingAccount and a SavingsAccount, as no “general” Account can be created.

If you look closely, you will see in the diagram that the entity name “Account” is italicized. This italicization is the convention used in UML for marking an entity as being an abstract entity. Because this is so subtle visually, so you can additionally add the notation “<<abstract>>” inside the top compartment of the box if you want to bring more attention to the fact.

Interpreting data models for user interface design

So why are data models so important in many projects?

First of all, the data model tells you what attributes are present for each entity. So if you are designing a form or a screen for editing a customer’s address, the data model tells you what fields you have to work with.

Likewise, the relationships between the entities are important for user interface designers to know, because these associations reveal how all of the data is related, and your application’s interface cannot be designed in such a way that it violates the relationships in the model. So if the data model allows customers to have multiple accounts, then you need to design the product to allow the user a way to view and access all of the accounts. This means that the product will look and behave differently than it would if customers were only permitted to have a single account.

Changing a data model to better fit the real world

You might say that some of the rules we’ve just discussed above for customers and addresses and accounts are not very practical for a real bank — two spouses should be able to share a joint account, for instance. And that’s correct — this is a highly oversimplified data model.

If you’re working with a data model that has been designed by somebody else, it’s often inevitable that you come to some disagreement over how the entities and relationships have been designed. In our bank example, you might argue that customers should be able to have multiple addresses on file, such as a work address as well as a home address. Or you might want the system to keep track of all of the address changes in the past. Or you might want address records to be shared by multiple customers in the same household, so that a change-of-address need only be done once, and the new address becomes effective for all of the customers sharing the address record.

If the design of a data model is hindering your ability to design a usable interface, because the designer’s data model doesn’t quite match the way your users want or expect things to be, then you should propose changes to the data model and discuss them in with your project team. Developers and project managers can be resistant to changing the data model because some types of changes can involve a lot of work, expense, and uncertainty.

Keep in mind that changing the data model early on in a project is much easier than making changes once the software has been built and is being used by users — there can be some very tricky data conversion and migration issues to consider.

Usability concerns in moving from a data model to screen designs

There is often a temptation to map one-to-one from data models to screen designs in a mechanical fashion, and in fact some systems exist that can translate data models or database schemas into rudimentary user interfaces. The use of entities often lends itself to having separate screens or tabs or other sections that correspond to various entities, but beware that this is not always desirable from a usability perspective. Sometimes there may be fields that logically belong near each other on the screen, but the fields may be stored in attributes in different entities in the model. And mimicking the data model too closely can often force the user to have to create the right instances of the right entities in the right places in order to get tasks done, which is a very poor approach from a usability perspective; this would essentially force the user to know all the details of the data model without having access to a copy of the data model diagram!

Focus on the users’ needs first. Use the data model to inform yourself of what entities and attributes are available, but then design the screens in a way that makes logical sense. Think about the work and tasks that the users have to do, and design task flows that guide them through the work with a minimum of memorization. Focus on designing a user-friendly experience first, and then worry about defining the mappings between the on-screen elements and the data model.

Summary

While this brief introduction to UML class diagrams only scratches the surface, it will hopefully get you started if you’re a user interface designer who hasn’t encountered data models before and now needs to be able to read and interpret them in a project. If you want to learn more about UML, a web search will uncover plenty of useful resources.

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.

• Interviews with users
• Interviews with managers and other stakeholders (if applicable)
• Interviews with subject matter (domain) experts
• Questionnaire surveys
• Observing users…
• using your product or prototype
• performing their tasks without your product, either with a competitor’s product, or by doing the task manually without a technology-supported solution
• Analyzing website analytics data: User demographics, frequently-searched keywords, heatmaps, usage patterns, etc.
• Literature review: Academic research, third-party market research reports, etc.
• “Documentation archaeology” from past projects

Some user characteristics for your product might be chosen “by design” when you define your target market and product positioning strategy. For instance, by targeting a product towards children, you’re intentionally restricting the age range of the target user group to a certain range.

If you are making any assumptions about your users and target market, it is a good idea to test your assumptions. But research costs time and money, and so especially in smaller projects, you will have to weigh the cost-benefit ratio of improving the quality of the information you’ll be using for future decision-making.

A persona or user persona is a brief textual description of a fictional character who is representative of a stereotypical user in a user segment. The persona describes some invented personal details about the character, explains in general terms what they do with the product, discusses the context or environment in which they use the product, and mentions some of the problems, frustrations, and concerns that they might face.

You should invent a fictional name and a descriptive title for each persona; for example, Carol Jones, insurance adjuster, or Bob Davis, middle-aged man wishing to book a family vacation. To make the persona more tangible and memorable, you might also include a photograph (perhaps selected from a stock photo repository).

For example, a sample persona for a new word processing product might be as follows:

Example persona: Alice Smith, aspiring first-time novelist

Alice is 29 years old, divorced, and has a two-year-old daughter. She has a bachelor’s degree in English Literature from a state university, and currently works full-time as a marketing assistant for a major pharmaceutical firm. Alice sees herself as a very artistic person, and dislikes the fact that her corporate job offers no real opportunities to express herself creatively. She is particularly passionate about reading historical fiction, and so she now wishes to pursue her long-time dream of writing her own novel in this genre.

Because of her job and child-care responsibilities, Alice tries to get her writing done in small blocks either early in the morning, or late in the evening after she has put her daughter to bed. On weekends, she enjoys writing while sitting in her favorite coffee shop. She is frustrated it takes her a lot of time to get warmed up and into the “flow” of writing, and because she only has short windows of time to work on her book, she doesn’t feel that she is making very good progress.

Alice is currently using Microsoft Word on her MacBook laptop, but she is finding it difficult to organize her notes, plan out her plot structure, and generate an outline. She has character and plot notes and multiple chapters spread across multiple Word documents, as well as hand-written notes in a notebook and on various loose scraps of paper, and switching between these is becoming a hassle. She feels she could be more productive if she could just get a better handle on organizing all of her project materials.

She would like to have her novel published by a big-name publisher, but she knows that this is difficult for a first-time fiction author. She is considering self-publishing but has not had an opportunity to research what is involved, and she is particularly worried about the costs involved. She would also like to make her novel available on e-book readers like the Kindle, but she is unsure of how to convert her manuscript to an e-book format and get it listed on major booksellers’ sites like Amazon.com.

The advantage of personas is that they help your team develop a shared understanding of the requirements of each user segment, and they encourage empathy with the end users of your product. By bringing to life someone from each user segment, with a human name and face, designers can design specifically with that particular user in mind. When designing a task flow or a screen, you might ask, “How would Alice want this information presented?” or “How would Alice react in this situation?”

Personas can also help focus usability tests and evaluations. For preliminary evaluations of a prototype, tests could be carried out by somebody pretending to act in the role of the persona, or at least with that persona in mind. (Of course, it is preferable to involve real users from the user segments, but this is not always possible.)

You can also use the personas to prioritize the requirements. For instance, one release could concentrate on the core features needed by the Alice persona, and then next release could concentrate on another persona.

Personas are not without criticism; many people find the invention of fictional names and personal details to be highly gimmicky. Trying to represent a diverse user segment with a single persona runs the risk that the persona doesn’t accurately represent a large percentage of the members of the user segment. And if you try to write up personas without ever actually investigating or speaking to real live users, these completely hypothetical personas may have no relation to reality.

The following is a list of some of the characteristics you might want to know about each user segment. Not all characteristics are relevant for all types of product — some may only be appropriate for software used at a workplace, for instance.

• Age
• Gender
• Educational background
• Language and culture
• Computing skills
• Physical abilities and disabilities
• Domain-related knowledge and skills (e.g., accounting knowledge for an accounting application)
• Job experience and competence
• Place in the organizational hierarchy
• Attitudes, motivation, and morale
• Persistence, patience, confidence, problem-solving ability, curiosity, ability to deal with change, etc.
• Frustrations and problems relating to the user’s tasks or activities
• General sources of stress or anxiety (e.g., deadlines, performance targets, workplace competition)

Additionally, you may also give some though to the context in which your users will use your product:

• Physical environment (e.g., home, office, factory, vehicle, oil rig, on-the-go in an urban environment, etc.)
• Social environment (position within organization, relationship to other groups, political and interpersonal factors, degree of freedom, influence in decision-making, etc.)

Every individual is different, of course, and there is a risk of creating generalized stereotypes that doesn’t accurately describe many users in a user segment, but it is still worthwhile taking the time to think about each characteristic. For some of these characteristics, you might describe an approximate range and an average. For instance, bank tellers at a particular financial institution might range in age from 20 to 50 years of age, with the average age being 28.

For each user segment or role, you may want to write up a brief profile, which can then be reviewed and discussed with your project team. A profile for a user segment can be presented simply as a bulleted list with characteristics described in point form. Or, you might use a matrix to compare user segments side-by-side. Alternatively, you can represent user segments by means of personas, which we’ll discuss in the next post.

End users are the people who will use the product in a hands-on manner a day-to-day basis.

The buyer is the person (or committee) who makes the final decision to purchase the product.

For enterprise software such as a call center management application, executives make the decision to purchase and install the system, but these executives usually never operate the software themselves.

Similarly, educational computer games for young children are not purchased by the kids themselves. Children may influence the purchasing decision, but it is the parents or other adults who buy the product.

Products purchased as gifts are another example of where the buyer is not the end user.

So while user experience design and usability testing must focus on the needs of the end users, your product must also simultaneously appeal to the potentials buyer, or it will never sell. Market research to understand buyers’ expectations and concerns is important and can strongly influence the scope and design of your product.