I always start my features by doing a design brief. This is a central place where we can house all of this discovery work and outline our strategy. These contain all of the links to other features this touches, any existing design work, and then lists out the problem we are solving, key tasks the user has to take, things we need to research or validate, and then finally the steps we are taking as a team to solve this problem. This is an excellent place to document all of the use cases we may see, any corner cases we’re concerned about, and any questions we may need answering.

Often our ideas for features require more validation before we can start work on them. Utilizing our research team, we gather together to determine what we need to discover and conduct interviews. This is where we lean on our users for feedback and document their responses. We then compare those responses against each other and determine a path forward.

Anything we’ve uncovered needs to be changed in our original documentation. I will work with the BAs to rewrite any requirements, and I will update my design brief. I personally like to stay very organized in this step and have all of our discoveries available in one place for easy handoff and also easy reference if you have to revisit this feature in the future.

I always start with a journey map whether it be myself or the designer completing them. This simplifies the process and also allows us to validate our workflows with the team prior to designing so we don’t waste time. This is also a good chance to map out any differences in approaches for validation. If I have 3 ideas on how to solve a workflow, I’ll do 3 different adaptations and present those to the team.

Sometimes we need to research other workflows, and sometimes we can figure out a workflow we want as it pertains to our application(s) and then we research how it’s best solved. We do get a lot of cases where we don’t have much research specific to the feature we’re on, but we will always try to take similar scenarios and apply them according to best practices. Example: asset utilization - not many other applications even provide this and if they do, typically they require a subscription to view. So we’ll take inspiration from blood glucose monitors, car service apps, etc, to find similar examples we could use for inspiration.

First, we will do low-fi designs where we simply outline our ideas to get them on paper. We like to list the pros and cons of our ideas as we do them so that we can make the best decisions moving forward. We will often validate these with the rest of the team as well.

After we determine which idea is best, we will utilize our Design System and our UI Lead to pick out the best components for the job. It is during this time that I ensure consistency in our behaviors, information access, and workflows. We then present this option (or many if we’re planning on testing more than one) to the team and create any prototypes necessary. This is also a good chance to check in with the dev teams to ensure what we are creating is feasible and if there are any technical hurdles.