OVERVIEW
Industry
Team
20
Phases
Discovery, Research, Ideate, Validate, Delivery
Duration
1 year
CONTEXT
The app was an internal corporate product with many integrations and a wide range of employee scenarios. At that time, the company had two mobile apps with partly overlapping functionality. This created duplicated work for teams, extra support costs for the business, and a confusing experience for employees.
I joined the project during this turbulent phase. After leadership validated both codebases and product potential, our app was chosen as the foundation for the merged product. We had to keep our existing structure and architecture, integrate missing functionality, and release one combined app within a limited timeline. This meant starting with MVP-level solutions for some features and improving them in later iterations after launch.
MY ROLE
I led the design work on the project, coordinating two other designers across roadmap, priorities, and delivery.
My work included
I worked closely with third-party services, evaluated integration ideas, asked many questions, explained design risks, and found compromises when external solutions did not fully fit our app logic.
I also managed research and evaluation activities, shared findings with stakeholders and the team, and supported design decisions with real product data. This included helping define analytics coverage and event taxonomy in Amplitude, then using funnels and user behavior data to validate observations and hypotheses.
Selected initiatives
with product-level impact ↓↓↓
01/
Validating the merged app experience
GOAL
KEY SUCCESS SIGNALS
01 /
Employees understand the merged app as one product and do not feel that they lost a familiar tool.
02/
Key employee scenarios remain easy to find and complete without extra help.
03/
Weekly usage stays aligned with the internal target and is tracked after release.
04/
App Store and Google Play reviews improve over the next iterations.
PROCESS
I organized the validation process: we defined hypotheses around the highest-risk parts of the merged experience, selected key scenarios where qualitative data was most important, checked whether employees still needed features that were not included in the MVP release, recruited respondents, and ran moderated usability sessions and semi-structured interviews.
week validation cycle
task-based missions
countries
mobile platforms
For this important merge, respondent selection was the first step of the testing process. We screened and selected candidates before preparing the final testing tasks and scripts.
Respondent recruitment flow with filtering criteria ↓↓↓
While recruitment was in progress, we prepared testing tasks, scripts, a session checklist, and respondent incentives. We tested the live app, so each session needed real setup in the system: the right office location, local workplace and benefits details, a booked desk, and a generated QR code for the test scenario.
The checklist helped us not miss important details ↓↓↓
Pre-session
Follow moderator script
Check screen sharing (show instruction if needed)
Help to cancel tested sick-leave and feedback.
Ask the participant's office address for gratuity.
In-session
Follow moderator script
Check screen sharing (show instruction if needed)
Help to cancel tested sick-leave and feedback.
Ask the participant's office address for gratuity.
Post-session
Follow moderator script
Check screen sharing (show instruction if needed)
Help to cancel tested sick-leave and feedback.
Ask the participant's office address for gratuity.
Feedback affinity map
After the sessions, we compared the results with our hypotheses. Most scenarios worked as expected, while two assumptions were not confirmed. We discussed the fixes and other findings with the team, then prioritized them in the backlog.
I presented the results not only to stakeholders, but also to the delivery team using user recordings from the sessions. For many team members, it was the first time seeing user research in action, so the demo helped make the design process more visible and our work easier to understand. This also continued as advocacy inside the team: I had to explain why a real thank-you for respondents’ time mattered and how it could support their loyalty for future testing.
To keep feedback coming after release, we improved the project visibility inside the company: created a landing page, used a dedicated corporate email for updates, added surveys for released features, collected a pool of employees open to testing, and monitored App Store and Google Play reviews.
DID WE MEET THE SIGNALS?
01 /
Merged app accepted as one product.
02 /
Months to make the integrations work smoothly after release.
03 /
Weekly usage tracked and supported with regular releases.
04 /
Store reviews improved significantly over the next iterations.
[YES],[YES] and[YES]!!!
02/
Building a continuous testing process
After the merged app validation, I wanted to make research easier to run on a regular basis. Large studies were useful, but they took time to prepare and could not support every product decision. We needed a lighter way to test ideas, prototypes, and improvements while features were still in progress.
I created a base of employees open to testing and set up several ways to find respondents: surveys, a dedicated project email, update messages, app store feedback, and a small in-app notification component. When employees shared negative feedback, we could invite them to test an improved version of the same feature instead of leaving the feedback unanswered.
I also introduced Maze for quick prototype testing. It helped us validate design ideas faster, collect structured feedback, and avoid spending development time on solutions that were not clear for users.
With support from the product owner, this became part of our design process: not a huge research activity once in a while, but a practical way to check new features before implementation.
Reflection
This project gave me a lot of ownership. I was expected to bring results, not to follow a fixed plan, so I had space to choose methods, test ideas, and build a process that worked for the team. It also helped me grow as a design lead. I learned how to manage priorities, delegate work, support and motivate other designers, set boundaries, and keep the design direction clear while giving the team enough space to work.
It was also a rare experience of being on the side of the product that became the foundation for a merge. It was not only about “winning” as a product. It also meant responsibility: to keep what already worked, carefully bring in missing parts from the other app, and help employees accept one shared experience without feeling that something familiar was taken away.
The biggest lesson for me was that research is not only about interviews or usability tests. It is also about creating the right conditions: finding respondents, motivating people to participate, explaining the value of research to the team, and turning feedback into product decisions.