Illustrations by DrawKit

Senior UX Designer, India Domestic Team, PayPal Bangalore

What I learned while working at a big organization!

A step-by-step guide to starting out your design work in any large-scale organization. A sequential process of getting it all right from the beginning.

Hierarchy

When you work at a big organization (a multi-national corporation, having offices in more than one country besides their home county), things work in a different structure than say a start-up.

The team structure is vastly different than mid to small-scale companies. Though the responsibilities of a UED team remain largely the same, in a big organization, the facilitation between cross teams increases by multiple folds, to say the least.

Steps for starting your first project (or any new project thereafter)

First things first – Gathering information (doing groundwork)

• Understand what market are you working for? Is it a specific country or global market?
• Is there a global flow for that market?
• If it’s for a local market, is there a flow specific to that market?
• Metric is your best partner. Get your hands on current metrics specific to the problem you want to address.
• Get current files from the UED team.
• If multiple domains are involved, reach out to each one of them early and get files that are live.
• Always cross-check the Sketch/Figma files you receive from different domain teams with the live version of the experience.
• If the two differ, document it and raise the issue with your manager(s).
• Check whether you can get your hands on the mobile app.
• If not, see how can you get access to the staging server (or an APK or a dummy account or a live account) to get the latest build.
• What is the platform you should work on i.e Android or iOS?
• Is there a reason for choosing a particular platform? Any metrics that directs you to choose one.
• What is the most common resolution you should start working on?
• Both platform and resolution information you should get from the analytics team.
• Get access to Confluence for following up with all product, tech, and design-related documentations.
• Get access to Jira for following all product, tech, and design-related user stories.

Kick-off meeting

• Get the product deck(s) from the product team.
• See if the PRD is well documented on confluence.
• Ensure there is a PRD written, if at all.
• Understand the business objective.
• Understand the product requirements.
• Understand what user pain points you want to solve for?
• How do you know it is a user problem?
• Before you dive into solution discovery it is always a good idea to get few things clarified from the product team. Start with some of the questions to be asked to the product team that helps in understanding the objectives clearly:

1. Customer persona — Whom are we designing this flow for?
2. Ask for competition flows.
3. What is the feature demand in the market — How many customers use this and why?
4. What is the purpose of the flow i.e clear concise value proposition, and how will this feature deliver the product strategy? What numbers does this affect?
5. What are the objectives of the feature release? How will we measure it?
6. What are our user profiles? Tasks and goals? This needs to be defined to achieve goal success rates for interaction design.
7. What are your product principles? Tech Limitations?
8. Ask for flow diagrams — showing details of edge and error cases — vetted by Engineering.
9. Any hypothesis or assumptions made? Discuss on them.
10. Product purpose?
11. The problems product wants to solve, not the solution.
12. Who is the product for? Companies (B2B), Customers (B2C), Users?
13. Details are great, but the big picture must be clear.
14. Describe scenarios.
15. Ask for release criteria?
16. Ask product for priority — Rank order of must haves vs good to have set of features—mapped to stages.
17. Results of usability tests.
18. Screen Shots mapped to flows.
19. Solution diagram (Arch).

UX Research

• Is there an existing research available to support user problems?
• If yes, see what was the final readout of the research?
• If not, then understand what you want to get insights from the users whom you want to solve for?
• If there’s no research done yet, that means the product requirements are merely assumptions that you need to validate first through research.
• Align with your UER team. Chalk out a plan for research.
• Start with experience mapping.
• Go ahead and do a current customer journey mapping.
• Start with some assumptions regarding the users with the help of Miro’s demo boards for pain points and validate assumptions with your research.
• The initial proposed solutioning can based on assumptions, and can be validated with usability testing and iterations.
• Conduct user research i.e get actively involved in drafting a discussion guide to understand the current situation of your users, observe interviews, conduct a couple of them yourself, share insights and help researchers compile the final readout of the usability study.
• With the help of a discussion guide, you should be able to understand how does a user go about achieving the current problem at hand.
• Analyze how other players are solving the same problem.

Design solution (Solution discovery)

• By the time you reach here, you already have done groundwork and research.
• You should have a good understanding of the users and their needs.
• Now when you want to start with the solution discovery, a good place to start is design thinking 101 by Norman Nielsen, i.e
• Empathize » Define » Ideate » Prototype » Test » Implement
• Empathize: You already have the Experience and Journey mapping by now. Use the research you have conducted that lays the foundation of understanding user needs.
• Define, Ideate, Prototype, and Test: Conduct a design studio for the rest of the design thinking process. Learn how to conduct a design sprint step by step.

Building product

Once your solution ideas have been validated through testing and iterating. It is time to build those solutions for a tech handoff and implementation.

• Right after the design sprint, conclude the sprint and communicate the summary of the sessions.
• Start building the solutions that came out as a result of the sprint. Use Sketch/Figma for wireframing and the final experience design.
• Create user flows on Figma/Miro for an end-to-end overview of use cases.
• It is always good to get the flows/design solutions validated from your organization’s design community. Get their early feedback and insights on the experience you have created.
• Get a slot for getting your designs and iterations reviewed periodically.
• I would also like to call out that as a UED you are not compelled to iterate your design based on every feedback.

Storytelling and presentation

• It is a good practice to maintain a timeline of the work i.e kickoff meetings to research, design sprint to hand-off.
• Also at this point of the stage, you must have to show it to the senior leadership and get insights and feedback.
• It is a good practice to document the way problem-solving has unfolded.
• There will be innumerous moments where you have to present the idea behind a solution, the rationale behind the decision. Try a storytelling format.

Handoff and Development

• Handoff the design files to the development team for implementation.
• If your organization uses Jira for managing product and tech user stories, it is a good idea to get onto Jira for managing design user stories as well.
• Once handed, keep a track of each tech and product stories that deal with experience and interface design
• You need to be in alignment with the engineering team for a seamless adaption of your UI design.

Going live and success metrics

• You need to be in alignment with the engineering team for the seamless development of pixel-perfect designs.
• Keep a close track of the product release cycle.
• See what you wanted to measure is being regularly tracked by prod and design
• All experience-related design touchpoints can be tracked by you.
• Make sure you document the success metrics and any other insights you gather after the launch.

Takeaways

This is a comprehensive list of steps that you should take for any project from start to end. The goal of this list is to act as a guideline for those who find themselves clueless about starting a project.

There is always room to add more steps to the list or go into much detail for any particular step.

Feel free to use this as a reference for starting any user experience project.