If you miss one of these, bad things happen (seriously):

Get feedback each step of the way

The most common reason that projects fail is because they solved a problem that didn’t exist, didn’t matter, or wasn’t collectively agreed upon.

The later the stage of the project, the higher the stakes. De-risk implementation changes with research. If it’s going to take 3 months to build a thing, better to plan carefully, right?

Add this research to your brief.

Document what you learn along the way. Document all use cases either in words, wireframes or mocks. Use this research to make sure that you’ve covered your bases. It may also help other members of the team understand a part of the product they’re less familiar with. In this example, we documented various states of rewards (there are many).

In project specific Slack channels, important information is bound to be shared and discussed. Anything of importance should be taken from Slack and documented in Notion. This is the responsibility of the designer or PM who is leading the project.

If your research is thorough, you should have a list of the difference user scenarios that your designs will need to address. Here’s an example. This example shows “user stories,” but “Job stories” are even better because less assumptions made.

You can also use screenshots and screencasts to document how things work today, and to capture various use cases to consider. In this example, each state of the existing reward details modal was documented in Figma. We used a similar strategy for the nav/layout redesign - see figma here.

Think early about how you might measure the success of your work. If we’re not already tracking user behavior, you may need to add tracking to gauge the impact of your changes.

Don’t just go off and design quite yet! You’ll want to validate that your problem definition is right, and your research makes sense. Talk to some people and get a 👍. Make sure they’ve engaged deeply 🤔!

If you don’t have a brief, create one. If you have a brief but you didn’t write it, talk with the people who did create it to verify that your understanding of the problem aligns with theirs.

If you only have one solution to propose, consider whether or not you have exhausted all possibilities. Multiple potential solutions make for productive conversation (e.g. prioritization, who’s doing what, combining parts of ideas into one).

Getting feedback from the team and from users, when time allows, is a critical part of the process. You’ll have to decide which method is right for you based on the project, timeline, etc.

Document whatever feedback you receive in the brief.

Mock up concepts before you go too deep. Spend some time sketching out ideas, whether that’s through sketches, wireframes or high fidelity mocks. The way you do it doesn’t matter, but the purpose is to 1) uncover aspects of the challenge ahead that you haven’t thought through yet and 2) get feedback early on. The more options the better. Below is an example of an early mock.

For technical projects, you may want to spend a few days doing a spike, since you’ll often learn as you build. For designers, more on the design process here:

This is when you want to write code. Congrats! Go off and write.

When stuff goes live, it exposes cases that weren’t known in plans. That’s OK, it’s going to happen. Go with the flow 🌊.

When launching a project, the designer and dev are responsible for alerting the team when something goes live. If you’re the point person on the project, check in with the dev to see which of you should post to #releases. If you’re unsure who the point person is, assume it’s you and ask if you need clarity.

As the point person, you are responsible for a smooth rollout, which means clear, descriptive and timely communication.

Your launch checklist should include what needs to happen before launch and who will be responsible. The list may include...

Make sure the thing that was built solves the problem well. Having our users do this for us is uncouth. Here’s how we typically do QA at Tremendous.

Ok, this thing is live. Did it work? For small stuff, you can measure with a gut-check. Product surveys via Hotjar can also be helpful. For big or mission-critical projects, it’s worth being rigorous. A/B test or track other analytics in Amplitude to make sure things work.

Get rid of design debt and code debt. Make sure that things are in good shape for the next person who picks up this piece of code or design.

Document what you’ve learned. If another member of the team starts working in the area of the app you build or changed, they should be able to read about how things work and where you left off.

Let’s be honest, this is a step that’s often skipped because everyone has moved on to other priorities. In an ideal world, we would look back and review performance after we’ve moved on — analyze usage data and confirm our solution solved the problem. Here’s a good example of coming back to a project several months later.

This brief below includes a list of problems, user jobs, competitive research, user research, design iterations, rollout plan, and more. We went through many stages of feedback and iteration in order to come to an excellent solution. By the time we launched, feedback was positive across the board both internally and from clients.

This was an area of the app that was both complex and old. Most of the work went into understanding what already exists and why. This was a complete redesign that also incorporated some client feature requests.

The Visa card page is a good example of the launch and iterate process. We were continuously collecting and reviewing feedback (see here), and iterating on our designs based on the learnings.

https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/