knowledge-kitchen

User Experience Design - The Nexus of User Needs, Business Goals, and Technological Constraints

Ensuring software will work for the people who will use it, and…

1. Overview
2. Assumptions
3. Stages
4. Discovery
5. Design
6. Reflection
7. Conclusions

Overview

Concept

User Experience Design (UXD) is purported to be the design of products and services in a way that meets the needs, goals, and abilities of end-users.

Cross-Discipline

User Experience Design often requires a mixture of cross-discipline skills:

• Technological - e.g. comprehending what designs are technically feasible

• Business - e.g. internalizing the business goals at the core of all designs

• Psychological - e.g. predicting end-users’ behavioral tendencies in particular contexts

• Social - e.g. bridging the gap between business and product development through conversation and collaboration

• Aesthetical - e.g. abiding by conventions and norms in visual and interaction designs

Difference

User Experience Design (UxD) has overlap with, but is distinct from,…

• Visual design - e.g. the perfect static finished design of something visible; what used to be called “graphic design”.

• User interface design - e.g. the visual design all interface components like images, buttons, icons and others that a user will see when interfacing with a product.

• Development - e.g. writing code

• Requirements engineering - e.g. determining what a project or product must achieve in order to be considered a success

• Market research - e.g. identifying competitors in the market and the behaviors and attributes of target end-user/customer demographics

Similar disciplines

User Experience Design (UxD), in practice, is very closely related to, and in some cases indistinguishable from,…

• Design thinking - “a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity”, according to its popularizer, Tim Brown, in the Harvard Business Review, or more simply “management consulting for creatives”, according to others.

• Customer exerience design (CxD) - the process of strategically managing a customer’s entire experience with a product or a company at all “touchpoints”, according to the Interaction Design Foundation

• Interaction design (IxD) - “the design of interactive products and services in which a designer’s focus goes beyond the item in development to include the way users will interact with it”, according to the Interaction Design Foundation

• Information architecture (IA) - “the practice of deciding how to arrange the parts of something to be understandable”, according to the now-defunct Information Architecture Institute

• Ergnomics or human factors - “an applied science concerned with designing and arranging things people use so that the people and things interact most efficiently and safely”, according to the Merriam-Webester dictionary

Assumptions

Overview

We design for people with a few assumptions and constraints in mind:

• People use things for a reason: typically a desire or need that they are trying to fulfill by interacting with a product or service.

• Creators have motives for making things: often profit, esteem from peers, “keeping up-with-the-Jones’s”, getting rid of extra money before end of fiscal year, etc.

• Technologies all have constraints: every tool has its inherent capabilities and limitations that constrain what can be done with it.

Everyone loves Venn diagrams…

… and User Experience Designers try to make all parties happy. This inevitably involves compromise and often disappointment.

In case you have been mislead

The involvement of User Experience Design in a process does not imply that a product or service is being designed to benefit the user, merely that users’ behaviors and preferences are considered as part of the design process, in addition to other constraints and concerns.

Examples abound of fantastically well-designed systems known to incidentally or intentionally harm people, for example so-called dark patterns, addictive game and social media designs, and tank display systems designed to more efficiently kill people.

Stages

Overview

The practices of User Experience design can be broadly divided into three stages:

• Discovery - the process of learning about the business goals, end-users’ needs, and any technical constraints

• Design - the process of drafting plans and blueprints for the product or service

• Reflection - the process of determining whether the design has been successful in achieving its goals

These phases are typically repeated with every iteration of a product or service.

Discovery

Concept

A subset of requirements gathering in software engineering projects as a whole, User Experience Design discovery begins by determining:

• organization’s business goals
• end-user’s needs and desires
• any technical constraints

Ideally, this discovery work would be done as part of a general requirements gathering process for a new project. However, quite often, no thorough requirements engineering has been done and the User Experience Designer is expected to perform this duty.

Method

As with requirements gathering more generally, User Experience Design discovery could involve:

• Stakeholder interviews - speak with the important people at the organization for whom the product is being designed.

• Competitive analysis - see what the competitors are doing in this same space: what they are doing well, and mistakes they have made that should be avoided.

• User interviews and observation - speak with potential users and observe them while they go about doing the things the product or service in development is intended to facilitate.

• Demographic research - review market research to understand the typical desires, problems, and needs of the average person in the demographic(s) the product or service targets.

Method (continued)

… and anything else a UX designer can get their hands on …

• review of an existing iteration of a given product or service
• review of any internal documenation of the product or service
• review of any analytics of the performance or success of the product or service
• any rumors or anecdotes that might give insights into the business goals or user’s needs

Artifacts

As a result of the discovery process, the following artefacts may be produced

• discovery document - a single document outlining what has been discovered, usually at a high level of abstraction
• requirements document(s) - one or more detailed documents outlining what must be done (e.g. business requirements, technical requirements, functional requirements, design requirements, content requirements)
• content strategy - a guide on how to approach the problem of developing content for the target audience
• personas - imaginary stereotypes of the different types of end-users of concern to help team members get into the end-user’s frame of mind
• user scenarios - a form of requirements sometimes misleadingly called “use cases” - that describe situations in which end-users may find themselves and how the product or service meets their needs

We will not elaborate any further on these discovery documents, but recommend a review of requirements engineering as a whole.

Design

Concept

The “design” aspect of User Experience Design is the drafting of the plans and blueprints for the product or service from a user’s perspective.

Design is the design of these plans, not the final implementation of the product or service itself (which is usually called “development”).

Method

User Experience Design process involves drafting sufficient written documents, diagrams, and sometimes prototypes to show all parties how a product or service would function over time, from a user’s perspective.

The level of detail of these documents depends upon the team culture and the needs of the project. They can range from “conversational” with a low level of detail to “formal” with a high level of detail.

Artifacts

The documents drafted might include:

• flow diagrams / activity diagrams
• ecosystem maps
• user journey maps
• content audit / content gap analysis
• information taxonomies
• site map / app map
• wireframe diagrams
• design patterns
• prototypes

We will elaborate on only the last four, which are arguably the most common in application development and provide the most benefit in practice.

Site/App Maps

Concept

Site/app maps are diagrams intended to show the number of categories of screens (e.g. web pages or app screens) that exist in a given application and how many screens exist or must be built within each category.

Example

An example of a simple site map of a shoe shop web site.

Communication goals

Site/app map diagrams are simple, fast, easy-to-draw diagrams that communicate…

• the number of unique design templates that must be created.

• what categories of screens exist in a site.

• the number of levels of screens within each category, if a user were to drill down step-by-step from each category landing screen to its children screens.

Prohibitions

Site/app maps, in order to best serve their purpose, should not…

• indicate more screens than you are capable of developing, filling with content, and maintaining - make a plan that is achievable.

• attempt to show every link from every screen to every other screen - draw lines for parent-to-child relationships only

• have more levels than absolutely necessary - err on the side of fewer levels.

• have more categories than necessary - err on the side of fewer categories.

Wireframe diagrams

Concept

For most purposes in software engineering, wireframe diagrams are the easiest artifact of User Experience Design to understand and produce, and provide the greatest benefit.

Example

An example of a high-fidelity wireframe diagram representing a web page screen in desktop view:

Example (continued)

Commendable features of this wireframe:

• black, white, and gray, except for the annotation number, which indicates that there is a corresponding set of notes that explain something not obvious on this screen.

• no shadows, fancy fonts, logos, and minimal use of icons or other graphics

• mostly placeholder dummy text, except for a few bits of “real”-looking text as needed to help explain the concept of the content

• clickable text is underlined

• images are indicated with a crossed-out box (often this is done with a gray box instead), with a descriptive label explaining the type of image

• high level of detail of what type of content will be on the screen, and where it will be positioned… little left to the imagination

Communication goals

Wireframe diagrams are simple, fast, easy-to-draw diagrams that communicate…

• what type of content will be on each screen.

• the approximate position and size of each piece of content, indicating its importance.

• hierarchical organization of all content.

• notes about any content or interactive behavior that is not obvious just looking at the diagram

• these diagrams should be self-consistent, where the same type of content is represented in the same minimalist visual style everywhere it appears.

Prohibitions

Wireframes, in order to best serve their purpose, should not include…

• color - everything should be black, white, and gray

• design - no shadows, fancy fonts, logos, icons or other graphics

• real images - use placeholder boxes with descriptive labels instead everwhere an image would go

• real text (also known as ‘copy’) - use ‘lorem ipsum’ placeholder copy instead, except where a bit of “real”-looking text would help make the intention of the diagram more obvious

Number

Each wireframe diagram acts as a template that is then re-used for one or more screens. Most application designers will produce distinct wireframe diagrams for at least each of the following…

• home screen - these are usually unique and follow a different template from other screens.

• each level of the site/app map - screens at the same depth level will generally follow the same, or similar, template - one for each level.

• unique screens - some screens are, by nature, somewhat unique in content and/or layout - for example “Contact Us” screens with forms, marketing brochure-like screens intended to give a unique look-and-feel, and others…

• overlays - any content that appears superimposed over other content when something is clicked or moused over, such as a hamburger menu.

Diagrammming Software

Tools of the trade

User Experience Designers use a variety of tools to make diagrams - each organization has their own preferred toolkit. Some common options:

• Pencil & paper - the timeless classic

• Draw.io - open source, always free

• Figma - free tier available, best-in-class today

Our choice (for beginners and for all UML diagramming)

When in doubt, use draw.io to build your wireframes, site/app map, and any other diagrams.

• no frills
• no cost
• perfect for a small app or website

Our choice (for pros and those who like good apps)

Figma is currently the best-in-class application for developing wireframe diagrams, prototypes, and many other sorts of diagrams and designs.

• complex functionality
• free trial
• a necessary tool for sophisticated apps or websites

Figma was acquired by Adobe for $20 billion in 2022… at this point it is still a surprisingly good piece of software.

Design Patterns

Concept

UX Design patterns are reusable solutions to common design problems in software design. For example, design patterns are often created to standardize…

• how the user is able to navigate using primary, secondary, and tertiary navigation, on whichever screen it appears

• how progress bars and other indicators of progress are displayed for any interaction where they may appear

• how interacting with search functionality works, wherever a search bar may appear

• how feedback messages, error messages, and the like are displayed for any interaction where they may appear

• step-by-step flows for how common multi-step interactions work from a user’s perspective, independent of which screen these flows are performed on

A note about design components

Reusable user interface design components are often used to help standardize how common user interface elements are presented to users in the software.

For example, a reusable component for a search bar might be composed of the following sub-components:

• a text input component, where the user types in their search query
• a search button component, which the user clicks or taps to submit their search query

This component and its sub-components would be designed once, and then instances of this single search bar component would be used throughout the application design wherever a search bar was needed.

Variations of this component might be designed to show all its different states of interaction, such as the default state and the state when the user has clicked into the search field which may look different.

Relationship of design patterns to design components

Design patterns indicate how common multi-step interactions work, and may be documented using design components and how they appear or disappear or change state over time.

For example, a design pattern for search may document…

• how the state of the search bar component changes over time as a user interacts with it
• at what point and in what form search results are displayed
• any other interactions and changes in component state that may be involved in the search process

Prototyping

Concept

Once initial wireframe diagrams have been drafted, it’s easy to put together a clickable prototype of an application using those wireframes. Benefits of a building a prototype include…

• for stakeholders to all agree that this is how the website will function.

• to count how many clicks or taps it might take for a user to get to the content that interests them.

• to show to potential end-users to get their feedback.

• to do a sanity check before spending time and effort building the site.

Our software choice

Figma has complex prototype functionality, but is best-in-class today.

• overkill for most non-professionals
• may scare away newbies.
• keep it simple.
• you’ve been warned.

Requirements

When creating a clickable prototype, meet the following minimal requirements:

• all buttons, links or other user interface components that allow a user to navigate from one screen to another must be functional in the prototype

• create as many variations of your existing wireframe diagrams as you need in order to make the prototype look “believable”; give a real sense of how the application flow might work… don’t take shortcuts.

• your prototypes must be designed to clearly show the way in which a user navigates from one screen to another, as well as how they solve the core use cases and needs your application is designed to solve.

Reflection

Concept

Reflection is the determination of success or failure.

In order to meaningful determine success or failure of any initiative, clear goals must have been elicited and documented during requirements gathering at the start. This obvious fact is often overlooked in practice.

Methodology

Teams have a variety of choices on how to observe the level of success or failure of their production:

• User Acceptance Testing (UAT) - end-users are given the opportunity to use the product or service to perform specific tasks and provide feedback on whether it fulfills their needs.

• User research and user testing, including interviews / observation of end-users - end-users are interviewed or observed to see if they are using the product or service as intended.

• A/B Testing - two versions of a product or service are launched simultaneously to see which performs better.

• Analytics - data is collected on how end-users are using the product or service, and this data is analyzed to determine if the product or service is meeting its goals.

Conclusions

At this point you have a just enough information to get into trouble starting to design experiences, including site/app maps, wireframes, and building clickable prototypes. Go for it!

• Thank you. Bye.