01.
Persona polishing
Our core product team went through several rounds of defining the primary persona, eventually settling on the Lead DevOps role. I was pleasantly surprised by how open and forthcoming most of the Lead DevOps interviewees were.
TRACE / BITRISE
CI/CD PLATFORM BUILT FOR MOBILE DEVOPS
April 2020 - December 2021
B2C/B2B
HUNGARIAN OWNERSHIP
Bit breakdown
1
Bitrise, an established mobile build platform and well known within the app development community, acquired the London-based start-up Trace for its expertise in mobile crash detection and reporting.
2
Building mobile software is an ongoing challenge of version updates, maintenance, and inevitable deprecations. In this landscape, the process of finding and fixing bugs must be fast, efficient, and cost-effective.
3
Crashes in mobile applications rarely stem from a single catastrophic error; more often they result from the gradual accumulation of minor quirks and inconsistencies. By studying historical crash patterns, these seemingly small anomalies can be modelled into formulas that improve prediction and detection of future failures.
4
Importantly, not all crashes originate in the app’s source code itself. They can also be traced to issues such as poorly assembled or compiled builds. Maintaining a wide field of visibility across potential points of failure is therefore essential, but increasingly challenging as systems and dependencies grow more complex.
10 Backend Engineers
1 Front End/Full stack engineer
Developers code bases:
React
Java
Xcode
4 Product Designers
Softwares I used:
Figma & Figjam
Axure
Story Book
Jira
Bit breakdown
1
Bitrise, an established mobile build platform and well known within the app development community, acquired the London-based start-up Trace for its expertise in mobile crash detection and reporting.
2
Building mobile software is an ongoing challenge of version updates, maintenance, and inevitable deprecations. In this landscape, the process of finding and fixing bugs must be fast, efficient, and cost-effective.
3
Crashes in mobile applications rarely stem from a single catastrophic error; more often they result from the gradual accumulation of minor quirks and inconsistencies. By studying historical crash patterns, these seemingly small anomalies can be modelled into formulas that improve prediction and detection of future failures.
4
Importantly, not all crashes originate in the app’s source code itself. They can also be traced to issues such as poorly assembled or compiled builds. Maintaining a wide field of visibility across potential points of failure is therefore essential, but increasingly challenging as systems and dependencies grow more complex.
10 Backend Engineers
1 Front End/Full stack engineer
Developers code bases:
React
Java
Xcode
4 Product Designers
Softwares I used:
Figma & Figjam
Axure
Story Book
Jira
Bit breakdown
1
Bitrise, an established mobile build platform and well known within the app development community, acquired the London-based start-up Trace for its expertise in mobile crash detection and reporting.
2
Building mobile software is an ongoing challenge of version updates, maintenance, and inevitable deprecations. In this landscape, the process of finding and fixing bugs must be fast, efficient, and cost-effective.
3
Crashes in mobile applications rarely stem from a single catastrophic error; more often they result from the gradual accumulation of minor quirks and inconsistencies. By studying historical crash patterns, these seemingly small anomalies can be modelled into formulas that improve prediction and detection of future failures.
4
Importantly, not all crashes originate in the app’s source code itself. They can also be traced to issues such as poorly assembled or compiled builds. Maintaining a wide field of visibility across potential points of failure is therefore essential, but increasingly challenging as systems and dependencies grow more complex.
Developers
code bases:
10 Backend Engineers
1 Front End/Full stack engineer
React
Java
Xcode
Softwares
I used:
4 Product
Designers
Figma & Figjam
Axure
Story Book
Jira
PERSONA - LEAD DEVELOPER
"Catch bugs
before users do."
Omar’s team take a pragmatic approach, often building extra functionality into the app to cover gaps in monitoring. It works as a stopgap, but it’s not ideal and was never meant to be permanent.
Omar's challengers
Mobile app development aimed at building stable applications across a wide range of devices is an exponentially complex task.
The team is small — just seven experienced developers — which means resources for monitoring and on-call support are limited. Despite this, they must ensure that every release is stable and reliable, while also continuing to deliver new features at pace.
With a release cycle of just two weeks, the pressure to balance quality, stability, and speed of delivery is constant.
PERSONA - LEAD DEVELOPER
"Catch bugs
before users do."
Omar’s team take a pragmatic approach, often building extra functionality into the app to cover gaps in monitoring. It works as a stopgap, but it’s not ideal and was never meant to be permanent.
Omar's challengers
Mobile app development aimed at building stable applications across a wide range of devices is an exponentially complex task.
The team is small — just seven experienced developers — which means resources for monitoring and on-call support are limited. Despite this, they must ensure that every release is stable and reliable, while also continuing to deliver new features at pace.
With a release cycle of just two weeks, the pressure to balance quality, stability, and speed of delivery is constant.
PERSONA - LEAD DEVELOPER
"Catch bugs
before users do."
Omar’s team take a pragmatic approach, often building extra functionality into the app to cover gaps in monitoring. It works as a stopgap, but it’s not ideal and was never meant to be permanent.
Omar's challengers
Mobile app development aimed at building stable applications across a wide range of devices is an exponentially complex task.
The team is small — just seven experienced developers — which means resources for monitoring and on-call support are limited. Despite this, they must ensure that every release is stable and reliable, while also continuing to deliver new features at pace.
With a release cycle of just two weeks, the pressure to balance quality, stability, and speed of delivery is constant.
Top 3
pain point themes
After a series of customer interviews run by our squad’s dedicated researcher, we started to build a clearer picture of where potential customers were experiencing pain points. Three key themes emerged:
1 - All the data but no focus.
The team had gathered useful data, but the problem was that it offered little insight into what led up to each incident. Crashes only became visible after they happened, meaning we had to work backwards to piece together the chain of events.
2 - Exponential probabilities.
3 - The tech stack of data calls & relays.
Top 3
pain point themes
After a series of customer interviews run by our squad’s dedicated researcher, we started to build a clearer picture of where potential customers were experiencing pain points. Three key themes emerged:
1 - All the data but no focus.
The team had done a good job at gathering data, the catch was that it didn't give any leading insight into what had lead up to the incident. Crashes most noticeably only showed up post the incident so you had to go back in time trying to establish the chain of incursions.
2 - Exponential probabilities.
3 - The tech stack of data calls & relays.
Top 3
pain point themes
After a series of customer interviews run by our squad’s dedicated researcher, we started to build a clearer picture of where potential customers were experiencing pain points. Three key themes emerged:
1 - All the data but no focus.
The team had done a good job at gathering data, the catch was that it didn't give any leading insight into what had lead up to the incident. Crashes most noticeably only showed up post the incident so you had to go back in time trying to establish the chain of incursions.
2 - Exponential probabilities.
3 - The tech stack of data calls & relays.
PARTS I PLAYED IN
PARTS I PLAYED IN
PARTS I PLAYED IN
SOME OF THE PROCESS
SOME OF THE PROCESS
My most notable achievements:
Optimised the Software Development Kit (SDK) registration process, reducing onboarding time by 2–6 hours.
Boosted user re-engagement by 40% by redesigning the crash events journey to display millisecond-level time series data.
01.
Persona polishing
Our core product team went through several rounds of defining the primary persona, eventually settling on the Lead DevOps role. I was pleasantly surprised by how open and forthcoming most of the Lead DevOps interviewees were.
01.
Persona polishing
Our core product team went through several rounds of defining the primary persona, eventually settling on the Lead DevOps role. I was pleasantly surprised by how open and forthcoming most of the Lead DevOps interviewees were.
02.
Workshop Wonders
I helped facilitate several team workshops where we mapped out users’ optimal registration flows when setting up their mobile app in the Trace environment.
02.
Workshop Wonders
I helped facilitate several team workshops where we mapped out users’ optimal registration flows when setting up their mobile app in the Trace environment.
02.
Workshop Wonders
I helped facilitate several team workshops where we mapped out users’ optimal registration flows when setting up their mobile app in the Trace environment.
03.
Epic breakdowns
I often joined development refinement sessions to gain a clearer understanding of a domain or to identify the next product objectives that required my attention.
03.
Epic breakdowns
I often joined development refinement sessions to gain a clearer understanding of a domain or to identify the next product objectives that required my attention.
03.
Epic breakdowns
I often joined development refinement sessions to gain a clearer understanding of a domain or to identify the next product objectives that required my attention.
04.
Use case simulation
After defining the scope of an epic and its sub-tasks, I led “How Might We” ideation sessions while the topics were fresh, generating a rich pool of ideas that could be turned into clickable prototypes.
04.
Use case simulation
After defining the scope of an epic and its sub-tasks, I led “How Might We” ideation sessions while the topics were fresh, generating a rich pool of ideas that could be turned into clickable prototypes.
04.
Use case simulation
After defining the scope of an epic and its sub-tasks, I led “How Might We” ideation sessions while the topics were fresh, generating a rich pool of ideas that could be turned into clickable prototypes.
05.
Design language
After reviewing our researcher’s findings and moving away from the predominant use of the brand colour purple, we concluded that a sage green could introduce a calming, subtly celebratory tone. Huge thanks to Harry Hogg, our Lead Frontend Engineer, for his keen eye and appreciation of design details.
05.
Design language
After reviewing our researcher’s findings and moving away from the predominant use of the brand colour purple, we concluded that a sage green could introduce a calming, subtly celebratory tone. Huge thanks to Harry Hogg, our Lead Frontend Engineer, for his keen eye and appreciation of design details.
05.
Design language
After reviewing our researcher’s findings and moving away from the predominant use of the brand colour purple, we concluded that a sage green could introduce a calming, subtly celebratory tone. Huge thanks to Harry Hogg, our Lead Frontend Engineer, for his keen eye and appreciation of design details.
06.
Component crafting
To avoid disrupting the design team, I gradually introduced updates to some outdated UI components. For example, I repositioned the card CTA to the bottom, improving the distinction between system and insight data.
06.
Component crafting
To avoid disrupting the design team, I gradually introduced updates to some outdated UI components. For example, I repositioned the card CTA to the bottom, improving the distinction between system and insight data.
06.
Component crafting
To avoid disrupting the design team, I gradually introduced updates to some outdated UI components. For example, I repositioned the card CTA to the bottom, improving the distinction between system and insight data.
07.
Concept - sketches
I was fortunate to work with a very receptive team during hack sessions, which ranged from 10 minutes to 2 hours. In just two 1-hour workshops, we finalised the wireframes for the overview page.
07.
Concept - sketches
I was fortunate to work with a very receptive team during hack sessions, which ranged from 10 minutes to 2 hours. In just two 1-hour workshops, we finalised the wireframes for the overview page.
07.
Concept - sketches
I was fortunate to work with a very receptive team during hack sessions, which ranged from 10 minutes to 2 hours. In just two 1-hour workshops, we finalised the wireframes for the overview page.
08.
Overview page is realised
I consolidated the data through a new, focused lens, giving Omar a clear overview of his app’s state. Key metrics included Health, Live Users, Active Users, New Users, User Events, Crash-Free Sessions (a positive way to present the data), Network Latency, and Version Adoption, all filterable by daily, weekly, or monthly views. Many thanks to our Lead Engineer, Harry, for his craftsmanship.
08.
Overview page is realised
I consolidated the data through a new, focused lens, giving Omar a clear overview of his app’s state. Key metrics included Health, Live Users, Active Users, New Users, User Events, Crash-Free Sessions (a positive way to present the data), Network Latency, and Version Adoption, all filterable by daily, weekly, or monthly views. Many thanks to our Lead Engineer, Harry, for his craftsmanship.
08.
Overview page is realised
I consolidated the data through a new, focused lens, giving Omar a clear overview of his app’s state. Key metrics included Health, Live Users, Active Users, New Users, User Events, Crash-Free Sessions (a positive way to present the data), Network Latency, and Version Adoption, all filterable by daily, weekly, or monthly views. Many thanks to our Lead Engineer, Harry, for his craftsmanship.
09.
Weekly sync ups
Trace/Bitrise had a strong social culture, despite our dispersed remote team. Our dedicated squad researcher often shared her findings, which frequently sparked further discussions and insights.
09.
Weekly sync ups
Trace/Bitrise had a strong social culture, despite our dispersed remote team. Our dedicated squad researcher often shared her findings, which frequently sparked further discussions and insights.
09.
Weekly sync ups
Trace/Bitrise had a strong social culture, despite our dispersed remote team. Our dedicated squad researcher often shared her findings, which frequently sparked further discussions and insights.
My most noticeable positive impact:
1: Optimised Software Development Kit "SDK" registration process by 2/6 hours of onboarding time.
2: Increased user re-engagement by 20% with the Crash events journey display of millisecond time series log data.
My most noticeable positive impact:
1: Optimised Software Development Kit "SDK" registration process by 2/6 hours of onboarding time.
2: Increased user re-engagement by 20% with the Crash events journey display of millisecond time series log data.
CRASHES SCREEN
< SLIDE >
EXAMPLES OF MY POSITIVE IMPACT ON
EXAMPLES OF MY POSITIVE IMPACT ON
CRASHES SCREEN
< SLIDE >
BEFORE
Blind list of high level stats
Having a list of all recorded crashes, app versions, and users was useful, but it didn’t provide any insight into what caused the crashes, where they originated, or how the events unfolded.
AFTER
Spot a crash in a flash
Omar’s crashes are marked with red flags in the micro-events timeline, showing interactions across 24 hours. The user journey stacks events and highlights problem areas for investigation. This level of insight wouldn’t have been possible without Harry’s full-stack expertise and appreciation for design.
Richer insights of crashes build up
CPU and memory usage are synchronised with the user journey stack, providing a much clearer picture of what may have contributed to a crash. This allows Omar to pinpoint when and where to check the log files to investigate the issue.
PERFORMANCE SCREEN
PERFORMANCE
SCREEN
< SLIDE >
PERFORMANCE SCREEN
< SLIDE >
BEFORE
Data with little insight becomes hard work
Data with little insight is hard work
The data provides no guidance on where to look or why. There’s also no way to tell whether a metric is underperforming or exceeding expectations.
AFTER
Pushing data upstream
Rolled-up trend data now gives Omar a clear, focused view of app performance — a capability made possible by Harry’s full-stack expertise and appreciation for design.
By presenting the performance trends of metrics in natural language statements, such as “Crash-free sessions (98%) are 9% lower compared to seven days prior”, we helped build trust in the data. Over time, this trust could be leveraged to introduce new benchmarks or strategies.
This approach was particularly important because Trace/Bitrise was promoting benchmarking as a key go-to-market USP.
Rolled up data trend values now informs Omar's through a focused lens.
By calling out the performance trend of a metric, in a natural language statements "Crash free sessions(98%) is 9% lower compared to 7days prior" help normalised the sense of trust between the data. Over time this trust could be expanded to present new Benchmarks or Strategies.
Why? Trace / Bitrise was focusing on pushing Benchmarking as a go to market USP.
BEFORE
The data doesn't have any indication of were to look or for what reason.
You don't any sense if a metric is under or over performing.
Data with little insight becomes hard work
AFTER
Pushing data upstream
Rolled up data trend values now informs Omar through a focused lens.
Wouldn't have been possible without Harry's full stack of skills and design appreciation.
By calling out the performance trend of a metric, in a natural language statements "Crash free sessions(98%) is 9% lower compared to 7days prior" help normalised the sense of trust between the data. Over time this trust could be expanded to present new Benchmarks or Strategies.
Why? Trace / Bitrise was focusing on pushing Benchmarking as a go to market USP.
CRASHES SCREEN
< SLIDE >
BEFORE
Blind list of high level stats
Sure it was handy to have a list of all the counted Crashes, App versions and Users, but they failed to give any insight into what/where/how events contributed to the crashes that took place.
Spot a crash in a flash
AFTER
Omar's crashes are indicated with Red flags in the micro events timeline. Interactions shown in 24 hrs of events. The User journey stack of events, call out problem "blocks" for inquiry. Wouldn't have been possible without Harry's full stack of skills and design appreciation.
Richer insights of crashes build up
CPU and Memory Usage are in sync with the User Journey stack of events. This gives a far more detailed picture of what could have contributed to a crash. Then Omar would know were and when to look in their log files to drill into the culprit.
EXAMPLES OF MY
POSITIVE IMPACT ON
TRACE / BITRISE
CI/CD PLATFORM
BUILT FOR
MOBILE DEVOPS
B2C/B2B
HUNGARIAN OWNERSHIP
April 2020 - December 2021
TRACE / BITRISE
CI/CD PLATFORM BUILT FOR MOBILE DEVOPS
B2C/B2B
HUNGARIAN OWNERSHIP
April 2020 - December 2021
Want to see/know more, and how
I may assist you in your project?
Want to see/know more,
and how I may assist you
in your project?
GET INTOUCH
GET INTOUCH
GET INTOUCH
bit
bit
by
by
bit
bit