Profile: Who am I?

1. The project kickoff

The first step in a major initiative is a kickoff meeting with everyone involved in the project. This is often split into multiple teams, which can include: creative and design teams, project management teams, and development teams, though this kind of segmentation does not always occur.

2. Gathering data: who to target & what to improve

Personas

When designing to solve a problem or provide a solution, it's important to know who you're designing for. A user persona is a clearly-defined, fictitious example of a specific user archetype. It is usually created through from insights already known about users combined with data gleaned through user interviews. Full-blown personas aren't necessary (and are hotly-debated within UX circles), user-centered design principles (i.e. designing for specific user types) is an important part of UX design. Multiple personas are to used identify when you're solving a problem for one group of users, but also to be aware when solving one group's problem might also be creating problems for another.

Personas are then handed off to Project Managers and Product Owners so they can generate user stories based on product requirements. While this occurs, UX can interview individual users to determine what works about the current process, what doesn't, what's missing, and what pain points might exist that users don't even realize is affecting them. User stories and epics, combined with a detailed heuristic analysis of the current offering and acceptance criteria from stakeholders, allow the designer to get a clearer picture of exactly what tasks each user/persona needs to accomplish in the context of their greater goals. These stories can be as simple as a statement, such as "As a Learner, I want to find courses easily so I can register quickly," or as complex as a series of such statements embedded within a parent epic that uses multiple stories to describe a greater overall goal.

3. Flows & journeys: finding gaps in the current process

Task Flows

Now the process of establishing task flows and user journeys begins. A task flow is an analysis of the steps a user takes to accomplish a task, whereas a user journey demonstrates the larger context of the user's exploration as they "journey" from awareness of a type of product or service to discovery of a specific one, comparison between similar offerings in the market, signing up, and using/purchasing something. A customer journey is similar, though may take a more marketing-specific approach rather than being focused on usability and accessibility, or may also include interactions between a customer and the organization outside of the usage of a web site or app.

These diagrams are useful in identifing potentially unnecessary steps in the process that can slow users down or create obstacles that impede progress. This is where user interviews become key factors in the UX process. It's important to ask questions, but it's just as important to watch as users try to accomplish tasks because they often don't even realize why a bad experience is bad; users often simply accept an experience as "the way it is", and can't always articulate why it's confusing or frustrating. But when you watch them try to do what's intuitive for them, negative patterns can become apparent.

4. Low-fidelity wireframes: a map, not a bucket of paint

Wireframes aren't design mockups; they're essentially blueprints for your web site or app. The benefit of wireframes is that they allow rapid iteration and prototyping without working about pixel-level design details. This vastly speeds up the design iteration process and allows quick changes and improvements in the user experience to be made. Wireframes are generated from the user stories if they are complete at this point, and review/feedback sessions can begin. Clickable prototypes can also be produced from the wireframes to gather early feedback from initial user testing.

The first round of wireframes are often intentionally low-fidelity. This means that most artwork is simple, if it is present at all. Images are often boxes and color is usually absent, and some content areas may simply be placeholders to be filled in later. Sometimes wireframes even take on a "sketchy" feel, to prevent stakeholders from accidentally reading too much into what they may see as the "design", since it is not yet present. This allows the focus to remain on usability without getting bogged down in the details. That said, not everyone follows this approach, and sometimes stakeholders have trouble visualing the final product when faced with low-fidelity wireframes - or they simply prefer to iterate on both usability and visual design at the same time.

5. High-fidelity wireframes, visual design & clickable prototypes

Once a wireframe is done, it's time to make it shiny. There is often some crossover between marketing and UX in this area, as visual designers can end up on either team. It's also not uncommon for a UX designer to have a background in visual design, which is true for me. Clickable prototypes can range from being based on low-fidelity wireframes to being pixel-perfect representations of a fully-implemented site - even to the point of utilizing live data sources. The purpose of prototypes is to gauge user acceptance and test the usability of a design before it goes live for a large group of users.

6. Content, UI assets, style guides & design pattern libraries

A complete style guide includes definitions for visual design and behavioral specifications. However, it doesn't take much to turn a style guide into a design pattern library by including engineering requirements for code implementation and an asset library. This can provide a one-stop shop for developers to get both style and implementation information. Generally speaking, code specifications are not the purview of UI/UX designers because there are often many engineering requirements that have nothing to do with the user experience. However, it is often helpful if these details are included, so long as the code structure makes sense and doesn't place undue restrictions on the engineering team's ability to innovate.

7. Analyize & QA: test, fix, rinse, & repeat

Most live projects are never "done". There are always improvements to be made, fixes to apply, and user feedback to consider. The "definition of done" is important for initial project completion, but once the project goes live it's important to allow it to evolve. User testing or bucket testing will allow ongoing analytics to be gathered, and this will allow future informed iterations to happen. During the initial project, however, active user testing allows early design revisions to be made in the interest of staying on target. Bug and defect reporting allows for ongoing code improvements while scrum retrospectives allow the entire team to be aware of their current velocity and where to make process improvements. The show never ends; there's always a sequel.