Daria Tsukali
Product Designer · UX/UI
I’ve been designing interfaces since 2019 and working in product design since 2023. I take projects from user interviews and hypotheses all the way to final designs and a design system. Open to roles in any industry. I work remotely from Bishkek, English B2.
Design process
- Role
- DesignOps
- Format
- Full-time, Click2Money
- Date
- 2024
Result
The team came to share one understanding of what it was building, why, and what to expect from design
Context
I put this process together at Click2Money, where I was the only designer: there were no requirements for design, and screens were made right away, with no stages. I had set up a similar process before at New Shift. It’s based on the Double Diamond, a model of two diamonds: the first is about the problem (discovery and hypotheses), the second is about the solution (designs and release). Before them comes problem framing, and after them, evaluating the results. Some of the steps I took from the practices of product teams at large Russian tech companies.
Problem framing
Every task starts here: the team shares the same understanding of what it’s doing and why, and there are fewer mismatched expectations later on.
- Why the designer needs it
You can’t design something you don’t understand. You need the context, goal and mission of the task.
- Steps
- Inputs. Everyone on the team shares ideas, insights and suggestions. The material is then sorted into inputs, mission, goal, audience and success criteria. A brainstorming session, with every suggestion documented.
- Goal and mission. Goal: what value the task brings to the company. Mission: how the solution helps the client. What the user gains. The goal is specific, measurable and time-bound.
- Audience. Not just “who our users are” but how many of them there are: how many people this is for, what share of all users that is, whether there’s a specific segment. The audience is one more piece of evidence that the task is worth doing at all.
- Success criteria. The metrics that will show the task is solved. What counts as success, what must not break, what to do if the result doesn’t meet expectations.
- How to save time
The designer gets full documentation for the task.
- Output
- A described task or a described problem
- A rough estimate of implementation time
- Preliminary success metrics, for users and for the product
Discovery
Starts once the team decides to take the task on. The point is to understand the problem without thinking inside a ready-made solution and without following the first idea. This is where the hypotheses for design come from.
- Why the designer needs it
To understand the users’ problem before drawing a solution.
- What it includes
- Experience. Analysis of the current solution, if there is one. An understanding of general trends, standards and best practices.
- Competitive analysis. 3–4 direct competitors and some indirect ones, their strengths and weaknesses. A table with scores from 0 to 5 and comments on what affected each score. Hypotheses are formed from what’s collected.
- User feedback. Existing feedback, conversations with support and with managers who are in direct contact with users, feedback from other departments.
- User research. If analysis and open data aren’t enough. The method depends on resources: surveys, in-depth interviews.
- Metric analysis. Quantitative data on user behavior in the metric being worked on.
- Data analysis. Results of past research, existing solutions, practices and methods that were used before.
- How to save time
- The product manager or an analyst takes on part of the data analysis.
- Use existing research and articles on best practices.
- Keep the focus on the key parts of the analysis.
- Output
- Analysis of the current solution or problem
- Reviews and support data analyzed, interviews and surveys done
- Task documentation: business, users, technology
- Artifacts: user flow, user story, CJM, competitive analysis
- Stakeholders have reviewed and approved the results
Hypotheses
Hypotheses are written up, and each gets a simple, cheap prototype. This gives material for a design session and for deciding which ideas to move forward with. Each hypothesis has a priority, and after sorting it’s clear what to take on first.
- Why the designer needs it
To evaluate the hypotheses and build low-fi prototypes.
- Steps
- Hypotheses. Formula: if we do [idea], we can positively affect [success criterion], because [why this idea is good].
- Low-fi prototypes. A simple, cheap prototype for each hypothesis.
- Prioritizing hypotheses. Two scores from 0 to 10: how much the hypothesis helps reach the goal, scored with the product manager, and how hard it is to build, scored with the developers. One is divided by the other to get a ratio, and sorting by it shows what to take first. Any other prioritization method works too.
- How to save time
- Writing up hypotheses can be skipped if the risk of hurting clients or losing money is low.
- Design the solution based on your own expertise.
- Output
- Hypotheses scored on how much they help reach the goal and how hard they are technically
- A prioritized list of ideas for further work
Designs
From exploring solutions to final designs. Together with the product manager, the solution is split into iterations that can realistically be done in the time available, and we choose what goes into the first version.
- Why the designer needs it
To clarify the details, define the functionality and prepare materials for the developers.
- Steps
- Breaking down the task. The task is broken down into its smallest parts, and the key elements and functionality are identified. The focus is on the minimum necessary solution, together with the product manager. This can include information architecture and visual design.
- Designs. Every interface state. Interface logic and copy that developers can understand. Notes that make implementation easier. Animation of screens and elements where it explains behavior.
- Review. Every user scenario is walked through, every screen is checked against the acceptance checklist, and hallway tests look for weak spots. A design review by another specialist, then a product review: an analyst or the product manager checks the work against the acceptance criteria from the task.
- How to save time
- Ready-made component libraries.
- Focus on the main use cases.
- Don’t draw every state, and cover the gaps by talking to the developers.
- Output
- A design review by another designer, an analyst or the product manager
- Tasks to come back to later are marked
Release
A check before going to production: the designer compares the implementation with the designs and the acceptance criteria. After launch, the interface is monitored in real conditions.
- Why the designer needs it
To check the implementation against the designs.
- What gets checked
- Match with the designs. Screens, states, copy and behavior match what was approved at review.
- Acceptance criteria. The implementation meets the criteria described in the task at the first stage.
- Post-launch monitoring. Tracking the success metrics set during problem framing.
- How to save time
Decide in advance who on the team checks what.
Evaluating results
Some time after launch, the team comes back to the solution and compares the results with the expectations from problem framing.
- Why the designer needs it
To understand what worked and what didn’t.
- Output
- An assessment of how well the results match the original goals
- Solutions that worked are identified
- What didn’t work
- Conclusions and the date of the analysis are recorded to compare against next time
- How to save time
Expected results, evaluation criteria and analysis tools are prepared in advance, at the problem framing stage.