knowledge-kitchen / course-notes

class: center, middle # User Experience Design Ensuring software will work for the people who will use it, and... --- # Agenda 1. [Overview](#overview) 1. [Assumptions](#assumptions) 1. [Stages](#stages) 1. [Discovery](#discovery) 1. [Design](#design) 1. [Reflection](#reflection) 1. [Conclusions](#conclusions) --- name: overview # Overview --- template: 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. --- template: overview ## 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 --- template: overview ## 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 --- template: overview name: similar-disciplines ## 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](https://readings.design/PDF/Tim%20Brown,%20Design%20Thinking.pdf), or more simply "management consulting for creatives", according to [others](https://interactions.acm.org/archive/view/september-october-2015/design-thinking-and-ux). --- template: similar-disciplines - **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](https://www.interaction-design.org/literature/topics/customer-experience) --- template: similar-disciplines - **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](https://www.interaction-design.org/literature/topics/interaction-design) --- template: similar-disciplines - **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](http://web.archive.org/web/20210514104452/https://www.iainstitute.org/what-is-ia) --- template: similar-disciplines - **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](https://www.merriam-webster.com/dictionary/ergonomics) --- name: assumptions # 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. --- template: assumptions name: venn-diagram ## Everyone loves Venn diagrams... ... and User Experience Designers try to make all parties happy. This inevitably involves compromise and often disappointment.  --- template: assumptions ## 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](https://www.deceptive.design/hall-of-shame), addictive game and social media designs, and tank display systems designed to more efficiently kill people. --- name: stages # 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. --- name: discovery # Discovery --- template: discovery ## Concept A subset of [requirements gathering](../requirements-engineering) 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. --- template: discovery ## Method As with **requirements gathering** more generally, User Experience Design discovery could involve: -- - **Stakeholder [interviews](../requirements-engineering/#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](../requirements-engineering/#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. --- template: discovery ## 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 --- template: discovery ## 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](../uml-diagrams/#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](../requirements-engineering) as a whole. --- name: design # Design --- template: 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"). --- template: design ## 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. --- template: design ## Artifacts The documents drafted might include: - flow diagrams / [activity diagrams](https://knowledge.kitchen/content/courses/software-engineering/slides/uml-diagrams/#activities) - 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. --- name: site-maps # 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. --- template: site-maps ## Example An example of a simple site map of a shoe shop web site.  --- template: site-maps ## 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. --- template: site-maps ## 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**. --- name: wireframes # 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. --- template: wireframes ## Example An example of a high-fidelity wireframe diagram representing a web page screen in desktop view:  --- template: wireframes ## 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 --- template: wireframes ## 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. --- template: wireframes ## 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](https://en.wikipedia.org/wiki/Lorem_ipsum)' placeholder copy instead, except where a bit of "real"-looking text would help make the intention of the diagram more obvious --- template: wireframes ## 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_. --- name: software # 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](https://draw.io) - open source, always free -- - [Figma](https://www.figma.com/) - free tier available, best-in-class today --- template: software ## Our choice (for beginners and for all UML diagramming) When in doubt, use [draw.io](https://draw.io) to build your wireframes, site/app map, and any other diagrams. - no frills - no cost - perfect for a small app or website --- template: software ## Our choice (for pros and those who like good apps) [Figma](https://figma.com) 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. --- name: design-patterns # 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](/courses/web-design/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 --- template: design-patterns ## 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](/content/courses/intro-to-computer-science/slides/object-orientation/#classes-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. --- template: design-patterns ## 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 --- name: prototyping # 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. --- template: prototyping ## Our software choice [Figma](https://figma.com) 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. --- template: prototyping ## 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. --- name: reflection # Reflection --- template: 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. --- template: reflection ## Methodology Teams have a variety of choices on how to observe the level of success or failure of their production: -- - **[User Acceptance Testing](../software-testing#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](../requirements-engineering/#interviews) / [observation](../requirements-engineering/#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. --- name: conclusions # 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.