• 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.

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.

That’s not incorrect, but there’s usually a little bit more to it than that. To design a product’s user interface effectively, you have to think through and decide on all of the following:

• What tasks and activities can the user perform with the application?
• How does the interaction proceed for each task? What steps and actions does the user perform and what steps and actions does the product perform?
• What is the overall visual style or appearance of the application? (For example, what will the basic page template or screen layouts look like, and what fonts, colors, iconography, and branding will be used?)
• What “places” are there in the application? “Places” could be pages in a web application, screens and dialogs in a desktop or mobile application, or even levels or locations in a game.
• How does the user navigate between the places (if applicable)?
• How will each “place” look? What controls and objects are available, how are they arranged, and how can they be manipulated or activated?
• What happens when the user activates or manipulates the controls and objects? What behavior is performed?
• What events does the application have to deal with that aren’t triggered by the user? (For example, do regularly-scheduled events occur? Does the application react to information arriving from another system?)
• What data or content does the application store, manage, and present? How is it presented or represented on the screen?
• What names or labels do you use to refer to all the things (data elements, objects, controls) in your application? How are the places, controls, and menus labelled?
• When errors occur, how is the user informed of the situation, and what opportunities are there for recovery?
• Are there different roles or classifications of users? What is each role allowed or not allowed to do?
• How will users get assistance when they’re unsure of how to use the application?
• How will you help new users figure out how the application works and how to get their tasks done?

Thinking through these issues isn’t enough, though. Since you’re probably working in a team, you’ll have to communicate your designs and intentions to the team members who will build and test the product. This communication can take the form of formal design documents and specifications, or prototypes and mockups, or perhaps even just face-to-face communication in front of a whiteboard.

And you need to be sure that what you design is feasible within the constraints of your project: It has to be implementable using your technical framework, it must be implementable with the skills of the team members available, the performance must be acceptable, and so on. Can the project team build the product at a reasonable cost and within a reasonable timeframe? And if the product is being marketed (as opposed to being a one-off custom project for a client), will the product sell enough copies to be profitable?

How do you figure out all of this? To start, you need to understand who will be using the product, and what they want and need. You’ll need to do this at the beginning of the project, and you’ll need to continually research and improve your understanding of your users as the project progresses, as these user requirements can often change.

We should note two things:

• Not all of the things in the above list may necessarily be done by one single designer! In most project teams, multiple people in different roles will take responsibility for different tasks. Examples of roles include product managers, business analysts, information architects, user interface or UX designers, usability specialists, developers, and so on. If your product is being developed for a particular niche or industry, such as banking or insurance or air traffic control, specialists with knowledge and experience in that domain will also play a key role in defining the product. Some organizations refer to these domain specialists as Subject Matter Experts, or SMEs.

• The above list, being focused on designing the user-facing part of a product, is not a complete list of all the things that need to be decided and designed for a software product. It excludes all of the technical design work, for instance. As since products are built by project teams, the project and its processes need to be planned and managed, and while this is usually considered a management task, there is no reason why this planning should not be approach with a design mindset as well.

UCD makes a lot of sense, and yet in many corporate environments, there is extraordinary management resistance to involving users in the product development process. Let’s examine some common objections to UCD and how you might address them.

• “You can’t do that! That’s not the way things are done here. That’s not our standard practice.”

Gently identify flaws in the company’s current products that could have potentially been avoided if a user-centered design approach had been used. If it’s too politically sensitive to criticize the company’s products, then try finding examples in your competitors’ products, or in mass-market products you’re familiar with.

If you’re forced to use a company-wide standard project methodology, ask whether the status-quo approach has always delivered flawless results, or whether there’s potential room for improvement. Lean, competitive organizations are often willing to entertain and embrace ideas for doing things more effectively and efficiently.

• “We don’t need to talk to users. The team has experts with all the knowledge to design the product.”

You’d be surprised at what you can learn from observing users doing their work, asking what problems they have with their current system or approach, and getting their ideas on what could be done better. It’s virtually guaranteed to challenge some of your long-held assumptions.

For enterprise applications, it often sounds like a good idea to only talk to the managers who oversee the users. But it’s important to talk to actual users who work with the system, and not just their managers: The reality of the way knowledge workers really get their jobs done frequently involves workarounds and special cases that their managers may overlook (or may not even be aware of).

• “We have a very tight schedule. We can’t afford to spend all that time talking to users and involving them in testing.”

Getting the requirements right is important so that you build the right product. This will prevent the team from wasting valuable time on unnecessary features and rework. Likewise, testing the product as it is developed to ensure that it really meets the users’ needs will avoid costly disputes with the customer (for bespoke enterprise systems) or failure in the marketplace (for mass-market products) after the product is delivered.

• “We don’t have staff experienced in these user-centered techniques.”

Your developers and business analysts can learn the techniques from books or training courses, or you might consider hiring a usability consultant.

• “Marketing is responsible for talking to the customers.”

Some organizations suffer from ugly and unproductive conflicts between competing managers and departments over their areas of responsibility. Try to build consensus around the need to establish the best process for ensuring a quality product, as all departments will benefit if the product is successful.

• “We don’t want to lose face in front of our customers if our staff asks questions that we should already know the answers to.”

Users and customers are usually more impressed that the team is taking the time and cares enough to understand their needs and provide a great product. If this is still a concern, then assign experienced senior staff to be involved with the users.

• “If we involve our users and stakeholders, they will all have different ideas and opinions that will divert our project’s focus off track.”

Ensure that all proposed user requirements undergo a proper review process to ensure that everyone’s wished-for features don’t gradually sneak into the product scope (this is known as scope creep or requirements leakage) without analysis and confirmation by an authority. A process such as the Quality Gateway described by Suzanne and James Robertson in Mastering the Requirements Process is recommended for controlling the quality of proposed requirements.

• “We can’t afford to let our competitors find out about our product development.”

Confidentiality is an important concern during the development of products to be sold on the open marketplace (it’s usually less of a concern for in-house enterprise applications). Consider non-disclosure agreements. Or, if possible, instead of working with users at your customers’ sites or recruiting users “off the street” (depending on your type of product), try to find users within your own organization.

• “I don’t want someone on our team to make promises to users that we can’t keep.”

Ensure that users understand that their suggestions and feedback are important, and that the project will try to accommodate as many reasonable ideas as possible, but that no guarantees can be made for any particular feature requests. Explain that the project has deadline and budget constraints and must satisfy multiple stakeholders, and that compromises must be reached.

• “We can’t afford to test with users. They might find a fatal flaw that will impact our deadlines!”

(Seriously?)  Much better to find serious flaws early, when they can be corrected, than to discover them after delivering the product!

[ad#AdSense_Banner]

Gould and Lewis’s seminal 1985 paper Designing for usability: Key principles and what designers think identifies the three key components of the UCD philosophy:

• An early focus on understanding users and tasks

Users should be involved in the project from its very inception. The designers and developers should have direct contact with actual users (or propsective users when a completely new product is being developed).

In order to be able to design a successful product, you must discover the users’ wants and needs, and you must understand users’ demographics, skills, knowledge, attitudes, and behaviors. For the design of hardware devices, anthropometrics (body measurements) may also be needed.

You also need to understand the tasks that the user will perform with the product, and that means understanding the relevant business domain. For example, if you’re designing a system to be used by bank tellers, you need to understand all of the tasks that bank tellers perform, and to do that you need to understand all of the terminology and concepts of retail banking.

In understanding the users’ tasks, you need to understand how the users are currently doing their work, and they might like to do things differently.

• Early and continual user testing with empirical measurement

Early on and throughout the project, users should be involved in validating the user requirements and evaluating the product designs. This is best done by constructing simulations and prototypes of the product, and observing users while they work with them. You can obtain qualitative data by recording users’ experiences and reactions, and asking for feedback.

Deeper insights can be obtained from quantitative data. You can define metrics for usability factors like learnability, efficiency, and error rates. You can then measure and compare users’ performance across different versions of prototypes.

Continual user testing helps reveal usability problems and defects in your designs and prototypes, and helps you identify improvements.

• Iterative design

The product should undergo a repeating cycle of design, modification, and testing, to fix identified problems, and to incorporate changes resulting from gaining an improved understanding of the users’ requirements.

“Build it right the first time” is a nice but unattainable ideal. For complex products, it always takes several tries to get it right. Iterative design strategies recognize this fact and ensure that the product is continually improved and fine-tuned so that the end product is indeed “right”.

A later 1991 paper by Gould, Boies, and Lewis added the following fourth aspect:

• Integrated design

The various aspects of the product that contribute to usability – i.e., the conceptual design, user interface design, documentation, training, help system, etc. – are all tightly interrelated. They should therefore evolve together in parallel and be under the same management. It is too problematic to attempt to manage them separately and sequentially.

All of these factors sound obvious and self-evident, and yet they are rarely done in practice. In later blog posts, we’ll discuss how to structure projects so that they involve users and employ an iterative approach. We’ll also explore techniques and practices for collecting user requirements and doing prototyping and user testing.

[ad#AdSense_Banner]