Process

Define

Projects arrive at various stages of development. Sometimes, epics are provided, and we collaborate to understand details. Other times, workshops yield comprehensive outlines, and my role is to ensure potential issues are addressed, considering both guest and business impact.

My primary initial objective is to identify business and user goals. Business goals align expectations. If absent, I advocate their creation, often prioritizing them in executive presentations. For user goals, I use personas, journey maps, analytics, and research.

When revamping old UX, I perform Business Requirements mapping for updated site sections, clarifying product impact.

Research

I've been fortunate to work with full research teams at two companies, leveraging their expertise in competitive analysis and emerging tech insights, streamlining implementation efforts.

When a research team isn't available, I conduct my own research, encompassing Direct and Indirect Competitive Analysis, and exploring emerging tech possibilities. Indirect analysis can offer fresh project perspectives or stretch goals.

I also tap into Design Libraries for existing patterns. Assessing if a feature needs new UX guides testing, while new features prompt updated library documentation.

Sketch

Now, let's dive into the creative phase! My approach to sketching varies based on project size. It might involve high-level flows or specific app behaviors, like handling push notifications across the app. For updates and refinements, I focus on comprehensive UX/UI work.

My typical workflow involves generating multiple design options, quickly identifying what works and what doesn't, and validating choices. I ensure I can articulate the reasoning behind design decisions, crucial for team buy-in. A key benefit is that while explaining, teammates often contribute solutions, transforming weak choices into strong ones.

Test

Testing is ever-present, regardless of deadlines. It ranges from in-depth consumer insights to informal internal testing, sometimes with treats for participants. External feedback has consistently proved valuable.

As a habit, I've also recruited a brain trust of designers that I can run my ideas through for quick feedback. Developing safe and constructive relationships, for this reason, has always been my first line of defense.

Finalize

This is the delivery phase. I typically provide Maps, Comps/Redlines, Wireframes/Annotations, and Accessibility details. I include assumptions and operational notes.

Noteworthy exclusions from delivery are UX refactoring with significant impact, contributing back to the Design Library, and proper documentation storage for future use.

A note on accessibility: When I have worked with a 3rd party vendor who validates accessibility, it helps to send off the documentation to them. They can validate the set up before tech starts to work on it. Getting a passing grade on the documentation means there will be less rework for development teams.

Build

Though this step falls under Tech's responsibility, I emphasize my continuous involvement in the project journey. Demo day holds significance as it reveals the progress.

If discrepancies arise between documentation and implementation, I can highlight them. While not a guarantee, I can request Product to address them as defects or in the backlog. Accessibility validation is also important at this stage. Minor adjustments are feasible within the next sprint, especially for multi-sprint work. Immediate feedback benefits from developers' coding mindset.

Sustainment

These teams ensure app/site health, addressing downtime and quick fixes. For projects I launch, I pursue post-launch improvements, discussing with Product and Tech for implementation. If not part of the sustainment team, I provide notes for the designer and product team.

This is also a good place to send notes for improvements to the Testing and Ops team, if you have one. It's helpful especially after being close with a project, when testing yielded a neutral result, to send notes on design options to be tested.

Iterate

I consider this the in-between-sprint-step.

I consider this the in-between-sprint-step. I'll take things from the project, sustainment, or workshop and backlog it for myself. If I have downtime, I usually push on these topics a little more. If I know a project, such as favoriting, is coming up, I'll push on a strategy for it. While I have this as the last step, I have done this throughout the cycle, keeping notes on thoughts that I have during the project.

Backlog Grooming

Sustainment and backlog grooming aren’t the sexy side of design. However, if happen to be the owner of the product on the Design side, it cannot be ignored. As a designer, I recommend sitting in these meetings. Often, side projects are handled in sustainment, having a designer review the work can vastly improve the user experience.

Design Thinking

Preferably, this occurs in Research, after Product defines a problem statement. Designing blindly can lead to misses or budget concerns. Facilitators establish context from the outset, leveraging the problem statement for informed blue-sky thinking, with competitive analysis and emerging tech solutions in mind.

Dev Sprints

Much has been written about this. Dev work runs parallel to my tasks. Active participation in tech meetings, when relevant, is crucial for Tech and Product alignment. My role involves candidly highlighting disparities and proposing solutions. Product and Tech collaboratively validate and work on solutions.

Spike Sprints

This can be Design Thinking, UX Sprints, anything that can be fit into a sprint, in timing with Dev. This also means we report how it’s going, if we have blockers, etc. This allows product to estimate the budget, validate the work and keep everything transparent.