PROGRESS REPORT
Our first focus was to clean-up and repair the existing Dont application (see Progress Report on DONT Legacy below), followed by getting the standalone Panic version developed and launched in the app stores for Apple and Google. Those tasks are now complete and links to all 8 apps are below.
Meanwhile, we are completing a design iteration for the Dont | Commercial version to serve as a replacement for Legacy Dont: one that works for both Parents/Teens and Supervisors/Drivers.
Two problems we need to discuss are as follows:
How you will license the Commercial version of Dont. I have some thoughts on this, which might look something like this:
A free version that has all the same features, but lacks batch onboarding of drivers and access to batch download / API access of driver status information.
A licensed back-end service with Google Sheet access to allow batch onboarding of drivers, as well as batch updates of driver status.
A licensed back-end service with APIs that allow driver management and reporting to allow integration with enterprise CRM/ERP systems like HubSpot or Salesforce.
All of the back-end services are available on Amazon Web Services; all that we would need to add are APIs and authentication.
We should re-think Dont | Commercial as a replacement for Legacy Dont, not a new series of apps. We are already being flagged in the iOS App Store review process for publishing Panic, with the reviewers thinking this is another version of the same app (they labeled it, initially, as spam).
-
Numerous bug fixes were required for the Dont legacy app:
Several packages and dependencies were very out of date and conflicting with each other.
Minimum and target SDKs were out of date and were updated to Google’s specifications, causing a cascade of logic changes.
Bugs that had to do with the Parent’s link building for the Child’s invite were fixed.
AWS Cognito’s SMS stopped working, which required making workarounds on the backend and frontend to continue development.
Work on the legacy app is now complete.
-
Numerous bug fixes were required to get Dont PANIC ready for launch.
Extensive API changes were needed to remove driving features and to send only the data needed for streaming.
A new AWS Cognito User Pool was created in order to make the SMS work as intended.
Driving features were deeply intertwined with the Panic feature, causing a lot of refactoring in the code base.
Streaming up-time sent from Vonage changed time zones and formatting, causing a lot of rework to existing time-based code.
We ran into issues with publishing in the Play Store and the App Store due to the app needing SMS verification.
Changes needed to be made to Google’s FireBase in order to use the invite function due to package names changing between the original version, Panic, and Commercial.
The developers and the design team have completed the final steps for getting Dont PANIC into the App Store and Play Store.
-
Designed an Admin App to replace Parent App.
Designed a modification of existing Child App to serve as a Driver App for a fleet of drivers.
New admin dashboard to allow easy view of phone usage for drivers.
New driver dashboard with a 'Clock Out' function to prevent the app from monitoring drivers when they are not working. See design details that follow.
We estimate 2 weeks of development remaining for MVP version of DONT Commercial.
App Reviewers are being difficult with multiple versions in the App Store that look similar (Apple reviewers tagged Panic as 'Spam').
Recognize that we are now managing TWELVE (12) apps for DONT: iOS and Android each for Legacy, Panic, Commercial.
Dont (Legacy) | Parent
Dont (Legacy) | Child
Dont PANIC | Parent
DONT PANIC | CHILD
DONT COMMERCIAL
PROJECT DESIGN PIPELINE
Free Airtable account creation required to view
phase 1: Discovery
WORKSHOP SESSIONS
Throughout the workshop sessions, KRUTSCH met internally to discuss features and requirements of Dont Commercial.
-
The designer who worked on the legacy app met with the designer for the commercial version to give them a project overview and list high-level requirements.
They made a plan for next steps: additional requirements gathering and workflows.
-
The design team met with the developers briefly to ensure their design ideas would be easy to implement.
SUMMARY RECOMMENDATIONS
Consult workflows from legacy app and recreate them for the commercial version, making changes where necessary.
Revise language from legacy app to reflect a commercial application (IE replace “parent” with “admin” and “child” with “driver”).
phase 2: Define
FEATURE SET, WORKFLOW & TECH STACK
KRUTSCH took the above findings to flush out a prioritized feature set, simplified workflow, and choose the right tech stack for Dont Commercial.
-
In order to repurpose Dont for an admin monitoring drivers in a commercial setting, there are a handful of considerations. The new admin dashboard requires an intuitive layout to organize a potentially large number of drivers. Drivers, meanwhile, need the ability to pause monitoring when they are not working.
Other than that, however, many of the features from the legacy app remain the same. Detecting and reporting rule violations, app requests, distress streams – all of those use cases are present in the commercial version.
-
-
We initially planned to create an admin dashboard as a separate web app. Partway through, however, we realized this would be needlessly complicated for a pilot version - especially given the time it would take.
So, we instead turned our focus to creating a minimally viable product. In the interest of getting a working app into the client’s hands as soon as possible, we decided to modify the existing parent app to serve as the new admin dashboard.
The phone app will allow an admin to monitor their drivers in real-time. At the end of the day, it will generate a Google Sheet to provide a table view, allowing for easy management.
This is a more efficient solution than creating a new web app, as it will allow us to reuse existing code.
STYLESCAPES
WORKFLOWS - ITERATION 1
WORKFLOWS - ITERATION 2
PHASE 2 CHECK-IN MEETINGS
-
Met internally to review the feature set and workflows. Decided to change from a web-based admin dashboard to a modified iOS/Android parent dashboard in order to save time and deliver a pilot version promptly.
phase 3: Design & prototype
WIREFRAMES & INTERACTIVE PROTOTYPE
Utilizing the established features and workflows, KRUTSCH builds out low-fi wireframes. We iterate concepts until we have a workable design model, which results in hi-fi storyboards and representative prototype of Dont Commercial.
-
We deemed low-fidelity wireframes to be unnecessary in this case. Much of the work involved would be retreading ground from the legacy app. In light of this, we moved ahead with storyboards to save time.
-
-
ADMIN DASHBOARD: FIGMA PROTOTYPE
Here you can see how the admin dashboard has been modified from the legacy parent dashboard. Convenient headers can contain a potentially large number of drivers on a single screen, in a way that is quick and easy to navigate. Admins can find drivers by report type (rule violations, warnings, distress streams, etc.) or by browsing their names alphabetically.
ADMIN - DRIVER DETAIL VIEW: FIGMA PROTOTYPE
Once the admin selects a driver from the dashboard, the flow is largely the same as in the legacy app. Rule violations, warnings and distress streams are logged under the “Report” tab, while app permissions are handled in a different tab. The “Guide” tab offers an explainer for status terminology and color coding.
ADMIN - MANAGE DRIVERS: FIGMA PROTOTYPE
The area where an admin can invite drivers and configure their rules and notifications has also been redesigned with a commercial setting in mind. Drivers the admin needs to invite are separated from the others, to ensure that the tasks demanding their attention are immediately apparent. This makes it easy to parse important information when managing a large number of drivers.
ADMIN - ONBOARDING PROCESS: FIGMA PROTOTYPE
Lastly for the admin side, onboarding has been adjusted to accommodate a large number of drivers. The same sorting method is used to distinguish drivers the admin needs to invite. Additionally, calls to action and warnings now indicate when drivers still need to be invited – an anti-frustration feature not present in the legacy app.
Two new settings allow for greater control in a commercial setting. Default rules and configuration settings allow the admin to define which settings are applied to drivers by default, saving time when adding drivers but still allowing for customization. The dashboard alert setting, on the other hand, controls how long it takes for alerts on the dashboard to be dismissed without the admin checking them manually. This prevents old alerts from piling up and clogging the dashboard.
DRIVER APP: FIGMA PROTOTYPE
Moving on to the driver app, not much has changed except for changes to terminology. References to “child” and “parent” have been replaced with “driver” and “admin.”
NEW DRIVER FEATURE - CLOCKING IN & OUT
There is one new feature worth noting on the driver side. Since this app will be used in a commercial setting, users of the driver app will need to be able to “clock out” and stop monitoring when they are not working. Doing so creates a log in the admin app, so that admins can check to make sure clock in/out times match with shift schedules.
RECOMMENDATIONS FOR NEXT STEPS
The next step is to develop the apps for iOS and Android based on the storyboards and prototypes. Our devs predict it will take two weeks to get the admin app up and running.
COMING SOON
phase 4: Develop & Deploy
Front & back-end development, product testing, bug fixes, app store deployment
KRUTSCH provides the development team, testing, cloud services, app store deployment, and ongoing support, as needed.