Are there users in your UX?

I want to discusses why there is a persistence of people — clients, developers, DevOps, project managers, product owners, stakeholders, system engineers, and more — who don’t know what User Experience (UX) entails.

I also want to discuss how UX is useful, how it can be championed, and how it can be integrated in the software development lifecycle.

Terminology

First and foremost, I’m not a programmer… one-hundred percent. Programming languages are a formal language which comprises a set of instructions used to produce various kinds of output.

Programming languages are used to create programs that implement specific algorithms. I don’t know Java, PHP, Ruby, or any other programming languages. I know HTML, CSS, and JavaScript, but that’s the extent of my knowledge. Terminology-wise, I want to define the following:

UI = User Interface (Designer)

Dev = Program Languages (Java, PHP, Ruby, etc.)

UI + HTML/CSS/JavaScript = Web Designer

Dev + UI = Front-End Dev or Web Dev

What is UX?

If you haven’t seen it before, there are many articles online about the differences between UI and UX. They typical feature images like this:

User Interface Vs. User Experience, Are there users in your UX?

If you search for the definition of UX you will find the following:

us·er ex·pe·ri·ence (‘yoo-zer ik-speer-ee-uh ns), n. 1. the overall experience of a person using a product, such as a website or computer application, especially in terms of how easy or pleasing it is to use.

If I can pass along any point it would be that a UXer needs users, and I would share my following favorite UXer quotes:

“You’re only a UXer if you’re doing usability testing, or at least you’re involved in a team that does.”

–Harry Brignull, User Experience Consultant

So if we are all on the same page, why are there so many people confused about the value of UX?

5 Reasons Why People are Confused About UX:

People don’t know what UX is or know UX principles

People don’t understand UX’s role, value, and how it’s included

The UX skill sets are all-encompassing and vast, which is confusing

UX is cool, everyone loves UX, and everyone wants to do UX… sorta

Everyone thinks they completely understand UX, but do UX badly

However, the truth is…

“Every time a person has a great experience with a website, a web app, a gadget, or a service, it’s because a design team made excellent decisions about both design and implementation — decisions based on data about how people use designs. How can you get that data? Usability testing.”

–Dana Chisnell, Usability Testing Demystified, A List Apart

So what is User Data and Usability Testing?

There is a huge list of UX Techniques that UXers employ to get various types of user data. Here are just some that you may be familiar with:

A/B Testing

Analytics

Card Sorting

Codesigning

Competitive Benchmarking

Directed Storytelling

Eye-tracking

Focus Groups

Intercepts

Observations

Prototype Testing

Remote Research

Service Safaris

Shadowing

Surveys

Usability Testing

User Interviews

Diving a little deeper, here are just a couple examples of a UX Techniques, the User Data yielded by those techniques, and how it’s those techniques are employed by a UXer:

Examples of User Data from UX Techniques, Are there users in your UX?

The reason Usability Testing is bolded above is because it’s the most valuable technique used in user-centered interaction design to evaluate a product (or parts of a product) by testing it on users.

Usability Testing can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. The following are the three main Usability Testing methods:

Moderated In-Person: A facilitator is co-located with the participant (often in a lab).

Moderated Remote: The participant and facilitator are in different locations. Screen sharing software allows the facilitator to remotely watch the participant.

Increase Exposure

Already if you look across the globe — small businesses, start-ups, corporations, etc. — these are some of the very different ways of how UX is being mixed in position-wise:

UI + UX = UX Designer

UX + Research = UX Researcher

Dev + UI + UX = UX Developer

PM + UX = UX Architects / UX Engineers

UX Team (with Designers, Researchers, etc.)

CXO (Chief Experience Officers)

UX Working in Dev and Sprints

UX in Waterfall

Waterfall is a linear approach to software development, wherein the development process and outcome at the beginning of, or even before, development, is planned. In waterfall software development flows in largely one direction (“downwards” like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. UX has to function at the very beginning, having enough budget, time, and users to inform the remainder process they won’t be involved with.

UX in Agile (aka Agile UX)

Agile development is a software development process whereby software is developed in iterative and incremental work cycles. Agile development is a flexible process that allows developers to change direction during the project and quickly respond to changing circumstances. In Agile UX the UX Design Team and Dev Team work together.

UX in Lean (aka Lean UX)

Lean software development (LSD) is a translation of lean manufacturing principles and practices to the software development domain. LSD is a concept that emphasizes optimizing efficiency and minimizing waste in the development of software. Lean UX unites development and business, through constant measurement and so called “learning loops” (build — measure — learn).

UX in Scaled Agile Framework

The Scaled Agile Framework (abbreviated as SAFe), is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team. SAFe is made freely available by Scaled Agile, Inc., which retains the copyrights and trademarks. In SAFe software development, Lean UX is employed within sprint cycles and as needed.

UX in AgileFall

AgileFall is a tongue-in-cheek term for a software development model where you are trying to be agile, but you keep falling into waterfall development habits. Here are just some red flags that your team may be in AgileFall:

The requirements are documented and fixed, each with target dates

You have sprints that are four or six weeks long

The daily standup is treated as a progress update meeting with people being told to work faster by someone senior to them.

The development team are isolated from the customer and rarely meet them

This is What a UXer Suggests

One of my favorite quotes concerning the adaptability and versatility of UX and UX Techniques is the following:

“There are many different project methodologies each with different strengths, weakness, advocates and evangelists. UX works in all of them. UX is methodology agnostic.”–Ben Ralph, Beaker & Flint

However, I’m now working on my fifth software development team, and with my fifth different software development methodology. If you have never seen Agile is Dead by Pragmatic Dave at GOTO 2015, I would recommend you do so. As Dave Thomas states, I firmly believe the following:

“Agile is dead. Agile is not what you do. Agility is how you do it.”–Dave Thomas, Agile is Dead, GOTO 2015

On every different software team, and in every different software development methodology, the following will work:

Get Requirements and Users

Co-Write Job Stories for New Projects

Share Processes

UX Should Work Sprints Ahead with Dev and PM

Do Retrospectives with Everyone: PM, UX, Dev, etc.

Get Requirements and Users

UX has to have access to users in the research, design, and development stages of the software lifecycle (in addition to product requirements).

By not incorporating users into the process of the software lifecycle, we’re offloading an internal problem onto the end user.

Thinking that this is practice is acceptable is a very harmful misconception, and is ultimately not within the best interest of the business.

Co-Write Job Stories for New Projects

If PM, Dev, and UX could collaborate on requirements and job stories (jobs-to-be-done framework) before mockups we:

Get answers/more complete answers

Wouldn’t do duplicate mock-ups

Employ better working strategies

Would be aware and eliminate
‘rush jobs’

Create informed mock-ups

Have more sound solutions

Share Processes

Tightly-knit, small, cross-functional teams have a much better chance of delivering value and delight to users.

Dev and Product should sit in on user testing and hear user feedback.

UXers should whiteboard with Product and Dev at early stages to resolve problems and foster understanding.

UXers should sit in on sprint planning and help write Jira tickets so that the right features get built in the right order.

Everyone must understand at least enough about the technology stack to have clear and useful discussions.

UX Should Work Sprint(s) Ahead with Dev and PM

After collaborating on job stories, UX can function sprints ahead of Dev.

UX explores and tests low-fidelity prototypes against user stories and users, giving Dev what they need.

Do Retrospectives with Everyone: PM, UX, Dev, etc.

The Manifesto for Agile Software Development proposes that a “team reflects on how to become more effective”.

Agile retrospectives can be used to inspect and adapt the way of working.

In Conclusion

Designing software or web apps with users in mind, or being a user advocate is a good start, but what distinguishes a User Experience professional from everyone else on the team — Dev, PM, PdM, Systems Engineers, UI Designers, Marketing, Tech Writers — is user research. So, make a place for UX on your team, and allow time for user research!