Summary

1. 🕵️‍♀️ Understand the problem.
2. ✍️ Design a solution.
3. 🧑‍💻 Build.

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

Get feedback each step of the way

• Make sure your understanding is right by getting input on your problem brief
• Make sure your design is right by getting input on your architecture doc or mockups
• Make sure what’s built is right by recruiting others to QA

🕵️‍♀️ Understand

Define the problem

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.

How to define the problem

• Write out the problems into a brief.
• For large or vague problems, break them down into specific sub-problems.
• Explain why the problem is worth solving! It would suck to spend 3 months on something that was already solved somewhere else, or otherwise didn’t matter.
• When possible, back up your rationale with data

Do your research

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?

• If your work is related to a preexisting feature, make sure that you yourself have tried out the feature on staging, our demo account or by logging in as a client. If you’re unable, ask for help.
• Talk to the people who experience the problem directly (user research)
• Talk to team members who deal with the problem
• Consider how many people this problem affects and how important they are. Is this a feature that only low tier/high churn users are requesting or will this help retain Tier I clients?
• Look at data in Amplitude, Fullstory, Delighted, Mode, Hotjar, etc. Ask for help from a dev if you can’t find what you need
• Look at the product feedback board for tickets related to the issue you’re solving
• If it’s code, check related commits or even pull requests. Were they useful? If not, get their timestamps and check Slack (#product-internal or #engineering)

Add this research to your brief.

Document how things work

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).

Record Slack convos

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.

List all possible scenarios

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.

Consider success metrics

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.

Validate and iterate

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 🤔!

✍️ Design

Deeply understand the problem being addressed

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.

More ideas are better than one

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).

Design, gather feedback, iterate

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.

• With little time, get feedback internally by sharing mockups, wireframes or prototypes, along with the brief. Jon, Kapil, Laura and Jane are all good sources of internal feedback.
• With more time and when there’s more at stake, reach out to users to schedule a call. If you can’t get them on the phone, try getting feedback via email or survey

Document whatever feedback you receive in the brief.

Validate ideas early

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:

🧑‍💻 Build

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

Validate and iterate

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 🌊.

🚀 Launch

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.

Plan ahead

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

• Rollout plan - will this be shown to all clients or will we release to a small group first
• Launch email - if applicable, how will we notify users about this new functionality
• Release notes - post a video in #releases on slack with as much context as possible, including a video/gif and other helpful materials or visuals.

QA

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.

Measure

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.

Leave things in a good spot

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.

Give an update down the line

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.

🍋 Examples

The catalog picker

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.

• Problem brief
• Figma designs
• QA process
• Rollout communication
• Release

Reward history revamp

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.

• Brief: New tables and filtering
• Brief: Reward details
• Designs: Figma
• QA: Docs (more on that here)
• Release (post in #releases)

Visa Card Page

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.

• Brief: Visa cards page redesign
• Brief: Visa UX issues
• Understanding the problem: Figma / Miro
• Design: Figma
• QA: Docs

Resources

🎩How to do a project

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

FAQs