Your browser may be failing you.

Instead, try Chrome or Firefox.

UX and You

whackronym, n.,

an acronym that is whack.

UX is a whackronym often used to abbreviate user experience.

UX and You

Wherever there is HCI
there is UX


UX and You

UX is an absurdly broad field

a broad field
UX and You

User eXperience

Tautologically UX concerns itself with any factor that influences a user's experience with a machine

UX Myths

Let's bust a few myths

UX Myths

Myth #31

UX design is a step in a project

Proper UX design touches upon most of the steps:

  • project objectives
  • business requirements
  • user research
  • tech architecture
  • interface design
  • aesthetic design
  • prototyping
  • usability testing
UX Myths

Myth #8

Stock photos improve a user's experience

UX Myths

Myth #3

People don’t scroll

UX Theory

Where did UX come from?

UX arose as a field of study and practice as more and more people in various occupations came to an unsettling conclusion.

UX Theory

Human innovation outpaces human understanding of innovations.

UXers seek to bridge the widening gap between people and new technology that can improve their lives

UX Theory

Useful technology multiplies human effort.

Paradoxically, it is this multiplier that causes the gap to widen.

A technology sufficiently complex to be useful will be too complex for a majority of its beneficiaries to understand how it works.

UXample

Touchscreens, for instance

Some short years ago, the touchscreen was born—an invention that literally puts data at our fingertips.

you
tech
UX Spectrum
UX Facets: Technology

A UXer strives to make technology serve the user.

And to prevent the user from serving the technology.

UX Facets: Psychology

The UXer serves the user

Understanding people and their motivations is the primary responsibility of the UXer

UX Facets: Aesthetics

The aim is to attract, not repel.

Purely functional technology is frightening, sometimes ugly.

Downtown
UX Facets: Economics

What do we offer the user?

A sponsor, client, or business provides the objective

Ground Control
UX Facets: Economics
Key Player #1

The Stakeholder

Identifies a problem worth solving
Provides support to solve it

Captain Picard
UX Facets: Aesthetics
Key Player #2

The Designer

Finds a solution and ably describes it

UX Facets: Technology
Key Player #3

The Developer

Devs can build anything

UX Facets: Psychology
Key Player #4

The User is unfulfilled

UX Facets: Psychology

Example User

human
UX Facets: Aesthetics

Example Design

UX Facets: Technology

Example Development

"The proper application of these algorithms to this problem will yield untold returns and stimulate an inordinate tidal wave of heuristics"

Dev Doge
UX Facets: Economics

Example Product

"We're taking this to market!"

Devsign Process

Where do we begin?

Over the years I've honed my approach into a eight step process.

  1. Objective: What's a problem worth solving?
  2. Audience: Who experiences this problem?
  3. Flow map: How would they experience an ideal solution?
  4. Specs: What features will we want to build?
  5. Tech: What tools will we need to build this experience?
  6. Prototype: Which features do we build first?
  7. Polish: How accessible can we make this solution?
  8. Cycle: How can we maximize momentum?
Devsign Process

1. Objective

What's a problem worth solving?

A very good place to start. Find a problem that you are passionate about solving and capable of solving given your resources and abilities. Define the goal, and depict success. Draw pictures, write stories, realize it any way you want to, any way that gets you and your team excited about solving that problem.

Devsign Process

2. Personas

Who experiences this problem?

Survey those who experience the problem you aim to solve. Figure out what drives them, what a solution would look like to them, and how much time or money they have to devote to solving this problem. Many call this market research or user research.

As you become familiar with the audience, archetypes will arise. Build dossiers around personas that exemplify the archetypes to give the team a clearer, outside perspective on the product. Give 'em a name, face, age, occupation, and all the relevant ethnographic data you can muster.

Devsign Process

3. Flow map

How would they experience an ideal solution?

Interaction design is at least 5-D: 3 spatial dimensions, time, and a number of other dimensions resulting from the user's choices. A flow map can help to convey and discuss the intracacies and complexities before you begin prototyping. A flow map of the interactions you aim to enable will make it much easier to break the product into discrete features and functions.

Devsign Process

4. Specs & requirements

What features will we want to build?

Before diving into the nuts and bolts, it's imperative to write about the product you plan to build in analytical framework. Rather than putting together an old-fashioned requirements document that few will reference and fewer will read, I like to break the product—as envisioned in the flow map—into features in a versatile task manager like Asana or Trello. Then we can stage the features into releases.

Devsign Process

5. Architecture

What tools will we need to build this experience?

With the wealth of frameworks and open source libraries available, it's likely we can bootstrap our efforts wihtout having to build everything from scratch. A comprehensive survey of the tools at hand will inform our architeture and save us a lot of work down the road.

Once we know what's out there we can design our architecture to support the features and specs. A flowchart can be a wonderful living document to illustrate architecture. Iterate on it as you build.

Devsign Process

6. Prototype

Which features do we build first?

The prototype comprises the minimum set of features necessary for a hands-on test of the concept. Why bother drawing pictures of an interface when you can build the interface and actually try it out? A working prototype accelerates progress like nothing else.

Said another way: if you want build a product, just start building it.

Devsign Process

7. Polish

How accessible can we make this solution?

Once you've got a working version of your idea, it's a good idea to polish the rough edges that might distract those doing the hands-on testing. It's much more difficult to polish an imaginary stone than a real one. Design in CSS, and only use mockups to develop the visual aesthetic, not to dictate the structure, dimensions, or (heaven forbid) a pixel-perfect replica of a drawing of an interface.

The character of the product may now be presenting itself through the prototype. This is good stage to examine naming, branding, and aesthetic. Call in the designers, make a mood board, give it a coat of paint.

Devsign Process

8. Development cycle

How can we maximize momentum?

Progress on a product no one has built before can be difficult to measure. So in early days it's best to focus on momentum, or its lazy cousin inertia. Giving team members freedom to create at their own enthusiastic paces, rather than focusing on blockers and linear processes, will keep productivity and morale high.

When a prototype starts building steam, you can maintain momentum with a staged work cycle that keeps the product folk, designers, and developers all busy. Many features do not follow a linear path from product, to design, to development, so choose a teamwork tool that allows features to bounce around as needed.

Try not to get bogged down in process though. Only build processes to solve real problems.

Where's the UXit?

Questions? Feedback? Donations?