Case Study: Using Rapid Software Prototyping
In this case study, we delve into the process of building Skanin using the rad model (rapid application development), a custom application designed for the automotive industry to streamline car repair status updates. Thanks to the development teams rad approach, we landed beta users on the platform within a few days of kicking off with the final product.
External Tools Used to Rapid Prototype
| Name | Usage | Starting Costs |
|---|---|---|
| Ionic | Framework used to generate app builds for iOS & Android | - |
| Twilio | Platform to enable SMS and MMS notifications | $0.0079 per SMS & $0.0200 per MMS |
| Google Places | Platform to access location-based data | $0.017 USD per usage |
| Serverless | Platform used to deploy the application backend without managing infrastructure | - |
| Sentry | Platform used for error tracking and monitoring | - |
| Mixpanel | Platform used for managing user analytics and flows | $0 / Month up to 20M monthly events |
The Challenge: Streamlining Car Repair Status Updates
From our cadre of automotive repair clients, we knew of some costly and manual processes. In particular, the repair status update process frustrated customers and burdened shops. We aimed to quickly build a tech proof-of-concept from scratch and palpably cut waste. More difficult yet, we only gave ourselves two working days.
Our Assessment: Following the RAD Approach
To assess the feasibility of the different implementations, K-Optional focused on distilling the issue, solution, and potential benefits. The scope couldn’t be too big, but there had to be a clear value proposition.
We identified two big bottlenecks: looking up customers and drafting notifications. QR tags promised to eliminate the first, and robust notification platforms would eliminate the human message entirely. In just 48 hours, we set out to test this assumption.
We believed that Skanin, a automotive custom software, would offer repair shops increased efficiency, reduced manual labor (i.e., fewer phone calls), and enhanced customer satisfaction.
Step 1: Designing an intuitive user interface
Using low-fidelity prototypes, we sketched out the flow of the custom automotive software by focusing on the car dealers experience, eventually breaking down the process into two steps:
- QR code scanning and pairing
- Repair status input
Thanks to an efficient design process, inspired by The Design of Everyday Things by Don Norman and the low-fidelity prototypes method, we established a solid foundation for the subsequent stages. This process allowed us to setup subsequent stages in our internal custom automotive software development.
Step 2: Creating an app that decodes QR codes
To expedite development, K-Optional chose Ionic, a framework that generates builds for iOS, Android, and web platforms. Ionic’s suite of components provided us with the necessary tools to breeze through UI development effortlessly. It also provided integrations with a mobile devices camera for QR decoding, allowing us to associate QR tags with customer phone numbers.
With the first portion of rapid software development done, we now turned our attention texting capabilities in the automotive software.
Step 3: Integrating SMS & MMS capabilities
We stood up a messaging backend in record time, thanks to the well-known Twilio API and Serverless Computing; we wrote code that sent SMS & MMS messages through Twilio, punting on server orchestration.
Step 4: Testing
Inevitably, application prototypes encounter bugs, a trade-off for the fast development time. To mitigate the number of issues, we ran a comprehensive test suite developed alongside the custom automotive software. Additionally, we designed and executed manual tests, simulating common user flows such as scanning QR codes and sending messages.
Finally, to address potential bugs or issues in production, we integrated a tool called Sentry. Sentry provided us with real-time error tracking and monitoring. Sentry pinged a dedicated Slack channel in the event of an issue, allowing us to be essentially “on call”. Thanks to this mechanism, we would later catch one glitch in production that we quickly patched.
Feedback Cycle
It was crucial to get input and insights from early users. Initial user feedback and metrics would inform future iterations and enhance Skanin’s performance.
We used the Google Places API to pull hundreds of repair shops in the area. The API notably doesn’t provide email addresses, so we wrote a scraper that crawled the website and parsed emails. As an aside, we open-sourced that scraper which people now use all the time.
In order to gain insight on user behavior, we integrated Mixpanel, an analytics tool, to track user flows and capture all events on the platform, enabling us to gain real time data on user behavior.
Both the direct user feedback and app analytics would serve a guide for future improvements. We would be able to identify any missing features, and prioritize enhancements for future iterations.
The Result: Achieving Rapid Feedback Loops with Skanin
The final product of Skanin provided value within 48 hours of ideation, thanks to rapid application prototyping and sound project design for our custom automotive software.
Our light code setup and efficient development practices were key factors in achieving a high level of output in such a small window. More importantly, tools such as Sentry and Mixpanel allowed us to quickly discover and address bugs. The average bug discovery to fix time was trivial, allowing us to maintain a rapid pace of development without compromising the quality of the custom automotive software.