User Experience, or simply UX has been a pretty widely used buzzword. Wikipedia explains UX to involve a person’s behaviors, attitudes, and emotions about using a particular product, system or service. The definition is so broad that it can virtually encompass all aspects of a consumer product. Aside from the field of human-computer interaction, design schools have been riding the same bandwagon. Browsing the course catalog at bootcamps, now the phrase is used in project management, digital marketing, and even in data science.
Often times you will encounter someone touting their “UX” expertise in persona writing, wireframing, storyboarding, rapid prototyping and interviewing. The matter of fact is that none of these working skills are particular to the modern UX enterprise, people have been working the same tasks in various capacities even before computing was a thing. Mastering how to write a persona or to wireframe says little about a person’s ability to comprehend, execute and refine user experience on a continuous basis.
The reasons for the vagueness and ambiguity surrounding the term “UX”, I believe there are two, one is to be praised and the other is to blame. Let us start with the blame. The tech industry, like any other industry with fads, rebrands itself every half a decade. UX is similar to phrases like “Cloud Computing”, “Web 2.0” in that regard. If we are truly concerned about UX the same way it is defined in Wikipedia, then user experience has always been a part of product design and development, since the beginning of time, the change is not one in the content of the work.
The reason to be praised? When UX becomes a skill set that the whole team regardless of job function deems important, this means we are entering an era where making something customers like, want and feel comfortable using is no longer just the job of a designer’s.
If UX is not just the job of a designer’s, and yet it has been around since the beginning of time, then what exactly is all the fuss about in this User Experience Revolution?
I believe that the user experience revolution is not just about designing based on user-feedback, it is about organizational processes innovation to faciliate interdisciplinary collaboration. UX is a process, not a task.
In a traditional product development team, the project manager gathers specifications from clients, the designers draw up concepts, the project manager works out timetables and the engineers build the products. The clients eventually see the product prototypes and provide feedback. The designers and engineers reiterate until the all the loose ends are tied up (well, ideally), and the team delivers the products.
The shortcoming of this traditional process is in the fact that there is no informed interpretations for why users do what they do and which aspects of user feedback are goal-oriented and which are merely artifacts of interacting with oudated products and workflows. And depending on the organization, the specifications for product development can be largely influenced or completely determined by the users (clients). Without a process in place for collecting, analyzing and interpreting user feedback, the users often do not come up with the best solutions to problems.
On the other hand, the whole UX fuss is about a user-centered design paradigm. With this paradigm in mind, the whole product development team is restructured to operate around processes that collect, analyze and interpret user feedback, with the goal of eventually capturing user behavior models (or task analysis models) that can be used to drive design and product QA/Validation.
User experience, in addition to the conventional wisdom in design and engineering, is augmented with psychological principles such as cognitive capacity and working memory, as well as principles from empirical research methods in handling stimuli in user studies.
The main difference between a team running modern UX process vs. one running a traditional product development process is that the traditional paradigm is all about plainly asking the users what they want. The blind spot in this approach is that what a user does right now without your product may just be an artifact of the old products and workflows available to the users at the time. Simply collecting what they do right now will not inform you why they perform the actions they did, and certainly will not pave ways to design new tools and interfaces informed by how the task should be approached.
(Figure: Traditional Product Development Process)
A modern UX process on the other hand, clearly understands that knowledge required by the task is often latent and can only be inferred from users’ actions. By observing what users do right now in their existing working contexts (without your product), it is important to study through observations (and think-aloud protocols) to uncover latent task knowledge that inform user actions, in order to create task analysis models that clearly specify the necessary knowledge and procedures to effectively completing the task at hand.
(Figure: Modern UX Process)
What is an example where understanding the difference between client’s existing procedures and their implicit knowledge is important? Well, take this example where your client is booking flights on a computer (keyboard-and-mouse) interface with lots of checkboxes and drop-down lists. Suppose you are building a multi-touch tablet app to replace the interface, in this case it is very important to understand that selecting from checkboxes and drop-down lists is a procedure that is an artifact of the interface and working context, and the task knowledge that should be captured is the information that need to be selected in order to make the booking, independent of whether they come in checkboxes and drop-down lists or not.
A good UX design should clearly model and distinguish between observed actions that are artifacts of interactions with an old interface, and actions that involve important latent knowledge to complete the task.
In order to execute this process well, a team running modern UX process is one that seamlessly integrate design, psychology, engineering, data mining, management and subject matter expertise to continuously engage users and refine the team’s understanding of the why, what and how of the working context and the solution. The keyword here is subject matter expertise, because there is no domain-independent or industry-independent UX as creating something for a gen X retiree will be quite different in practice from creating a similar product for a millennial student.
As a result, modern UX process can be conceptualized in terms of the following phases:
- Problem and Persona Definition
There is no solution if there is no problem to solve and no one to solve it for. The first and foremost task of any UX process is to clearly identify the persona of the target audience, for this purpose, you will want to describe the user in terms of age, education, economic background, access to technology, and as many other factors that the population is identified with. Then, you will want to articulate what the problem that this population faces is.
The key skill sets for this phase are design, psychology and subject matter expertise. Past marketing and sales experience may come in handy in furthering discussions and perfecting the definitions write up. This phase should produce a concise, unambiguous and informative write up.
- Contextual Inquiry, Task Decomposition and Task Analysis
After selecting a population and a problem, what is next? A lot of people may say hack something together and put them in front of your target audience. Nope! Remember that once you present your audience with stimuli, they will respond within the bounds you have set for them, and that usually means they are very likely to say what you want to hear, which is not what you want.
The next thing you want to do, is to learn about how tasks relating to the problem you defined are currently being performed in context, without your product. This way you can uncover the actions and knowledge associated with the task as well as actions that are associated with the particular methods this population is using right now (and have nothing to do with the task per se). At this phase, it is usually ideal to conduct purely observational studies with think-aloud protocols to qualitatively analyze how the task is currently performed.
The key skill sets for this phase are empirical research. psychology, human-computer interaction and subject matter expertise. This phase should produce a concise three-column table that clears documents at each step of the task (first column), which knowledge is recalled (second column) and what user actions were performed in the current user working context (third column). This task analysis model will be used to separate task-specific aspects from the context-specific and product-specific aspects of the study.
- Paper and Conceptual Prototype / Wireframe and Heuristic Analysis
With the task analysis model made, you have an understanding of what the task is and how it is currently performed. It is time to brainstorm, wireframe (even design something) and then perform heuristic analysis. Heuristics are nuggets of wisdom based on experience that can help us improve the design without throwing away bandwidth on empirical studies. Some examples of heuristics include padding or highlighting clickable areas to enhance visibility, design the interface to read from left-to-right (for English), and design the flow of actions in one direction.
Then, you want to validate the wireframe or prototype with the task analysis model you created to make sure it accommodates the interactions between knowledge and task actions.
Lastly, conduct another round of qualitative testing (ideally with think-aloud protocol) to empirically confirm your hypotheses about your wireframe or prototype. (Iterate if needed)
The key skill sets for this phase are design, rapid prototyping, psychology (especially cognitive), and subject matter expertise. This page should produce a multi-page flip book of the main interface views to adequately present the concept.
- Interactive and Logical Prototype
So when do you stop wireframing? The answer is simple: when your users like the concept, but start asking you about the technical details of how the data and the interfaces interact.
One very common mistake in UX is that people over-emphasize wireframing and begin elaborating their drawings and sketches with walkthrough comments to the point that it takes a solid hour just to review each iteration. You want to avoid that.
When the concept shows promise, move on to interactive prototyping where you can describe the business logic behind the interfaces. The interfaces can display forged dummy data and performs no actual data processing, as long as it gets the point across. If possible, try to prototype in the same (or similar) technology to what you hope to implement your final solution in, so you can reuse the interface code in the dummy prototype.
Lastly, conduct another round of empirical studies, this time you may choose between qualitative think-aloud protocols (more time consuming but more structurally informative on a per-participant basis), or quantitative methods (click trails, heat maps, response time, etc) to confirm your hypotheses about your prototype.
The key skill sets in this phase are design, rapid prototyping, engineering, and subject matter expertise. This phase should produce a deployable prototype that your target audience can interact with.
- Functional Prototype / Interface
The functional prototype in terms of purpose is not really that far from the interactive prototype in the previous section. The main difference between a functional prototype and its predecessor is that this iteration needs to produce something that is functional. This signifies a movement beyond just conceptual and logical discussions and begin exploring technical and practical implications of the solution.
The key skill sets in this phase are engineering, design, testing, QA and subject matter expertise. This phase should produce deployable early versions of the solution for the audience to interact with.
- Product Engineering
This phase encompasses further iterations on the solution.
At this stage, you will want to conduct quantitative studies that focus on identifying difficulty factors in interacting with the solution in quantifiable comparisons (e.g. click rates, response time, bounce rate, etc).
The key skill sets in this phase are engineering, design, testing, QA and subject matter expertise.
- Product Testing, QA and Product Improvement
The final phase of the UX process creates a feedback loop that feeds back into the product engineering phase, and at times, into the contextual inquiry and task analysis phase (if a feature addition is needed). In this phase, the focus is to deploy large-scale, continuous data collection mechanisms to inform the team of difficulty factors that exist in the system. If the difficulty factors resemble a significant departure from the team’s expectations of the solution, it may be appropriate to return to the contextual inquiry phase to study how the task is performed and identify actions that result from poor design, in order to conceptualize a new feature to improve the solution.
The key skill sets in this phase are empirical research, psychology, testing, data mining and statistics. This phase should be a long-running study of the population’s reaction to the deployed solution.