Process

"Process" is a word that makes many sigh, but I view it as a framework — something that can help one optimise their routine and, if regularly revisited, boost efficiency.

As I'm sure you know from your experience, every project's design→implementation process differs depending on the project scale, timeline, available resources, and so on. Yet, it's important to know the ideal process we aim for and understand the exceptions we make in each case, as well as why we make them.

I do prefer to track my teams’ workload in Jira, and so my preferred process is simplified to be easily translatable into the Jira (or another tracker) board columns as well as easily mapped against the most common team ceremonies (grooming, planning, etc.)

Building and maintaining a backlog

Every team has their key stakeholders, technical and UX debt, data and user insights and other sources to populate the backlog. It’s important to revisit the backlog at least once per quarter, reprioritise what’s relevant and archive irrelevant topics.

Checking your backlog against the key metrics, product vision, team goals will help to understand what’s worth exploring and can be taken to the next step.

Exploration

Do the groundwork! Don’t jump straight into the solution, but collect the project specific data and insights, do the opportunity sizing, do high-level flow diagrams and talk through the project with your key peers (Product, Design, Data, Engineering) and stakeholders to make sure the project doesn’t have any major unknowns that could negatively affect or completely block the implementation later.

Does this project still make sense? Take it to the next step!

Concept

Sandbox time! Explore possible solutions (there are plenty of workshop types to help with that) and share concepts with other designers, stakeholders and engineers to get valuable feedback and re-align on expectations and goals. User test if applicable and decide on the final solution.

Does your final solution solve the desired problem and still helps to meet the goals? Let’s polish it!

Final designs

Prepare all the states and cases. Re-test and incorporate feedback if necessary. Make sure all the assets (copy, imagery) are documented and accessible by the team. The project is ready to be groomed and properly estimated and translated into the development tickets.

Delivery

Design support during implementation is crucial! Fixing even a tiny UI issue before the PR is even built saves a lot of time for everyone (think of: build a PR and move a ticket to QA, QA to pick it up and test, find and document the UI bug, return the ticket back, Engineer to make a 3 minutes fix and create a PR again, and so on). Building and maintaining a close collaboration with engineers is saving time and money — yes, we’re serving users, but we also need to be a sustainable business to keep serving our users.

Learnings

Launch is yet another beginning. We need to keep an eye on how the feature performs, gathering data using all available sources, documenting and sharing learnings, and taking it to the next iteration if needed.

Also, it’s a good moment to clean-up the design file, document any design system requests if relevant, document the design debt if something was left-off from the first iteration implementation.

…and closing the loop ↻