Technical Documentation / Developer Enablement
BlackBerry IVY
Turning a complex edge-to-cloud platform into a developer-ready experience through architecture diagrams, GitBook documentation, and structured enablement systems.
01
Project overview
BlackBerry IVY is a cloud-connected in-vehicle software platform developed with Amazon Web Services to help automakers, suppliers, and third-party developers access, standardize, and extract insight from complex vehicle data. My work focused on making that platform easier to understand, easier to integrate, and far easier to support.
The biggest issue was a lack of clarity across the full developer journey — from initial setup to first successful data transmission. Without a clearer and more standardized experience, teams faced slower onboarding, harder support, and more friction building on the platform.
02
The challenge
BlackBerry IVY was built to unlock value from vehicle data, but getting started was difficult. Data lived across sensors, edge systems, and cloud services, making the integration path hard to follow. Developers were not just learning a new platform — they were trying to understand how everything connected, how data moved, and how to confirm it was working properly.
Unclear journey
Developers could not easily understand how everything connected across sensor setup, validation, cloud data flow, and downstream usage.
Fragmented documentation
Information was scattered across multiple sources with no structured onboarding path or standardized guides.
High troubleshooting friction
Without clear decision trees and support content, debugging integration issues was slow and inconsistent.
Slow time to value
The lack of reusable scripts and tutorials meant every team had to figure out the platform from scratch.
03
My approach
I approached the problem as an enablement and information design challenge. First, I reviewed the end-to-end developer journey to find where users were getting blocked. From there, I mapped the system visually and reworked the documentation structure in GitBook with clearer onboarding guides, standardized checklists, tutorials, reusable scripts, and troubleshooting flows.
Throughout the process, I collaborated with engineers and stakeholders to validate the experience and make the platform clearer, more repeatable, and easier to support.
04
System design
I created architecture maps and system diagrams that showed how data moved across the IVY environment — from sensor connection and edge processing through to cloud transmission and use. This helped turn an abstract technical environment into something developers could understand at a glance.
05
Developer enablement
I structured onboarding guides, reusable scripts, tutorials, support content, and troubleshooting decision trees so developers had a clearer path from initial setup to first successful data transmission. The goal was to reduce trial and error and make integration more consistent and self-serve.
06
Outcomes
The result was a stronger developer enablement layer around IVY that made the platform significantly easier to adopt at scale.
70% faster setup
Structured onboarding and reusable scripts reduced initial setup time dramatically.
90% faster troubleshooting
Decision trees and support content made debugging consistent and self-serve.
55% better integration reliability
Clearer architecture communication reduced errors and rework.
45% improved deployment readiness
Standardized guides and tutorials accelerated time to launch.
By improving how developers onboarded to IVY and understood the system, the platform became more scalable as an ecosystem. Better clarity meant faster time to value, lower support overhead, and a stronger foundation for connected vehicle features such as predictive maintenance, safety monitoring, and in-car services.
View more projects