Jepreto App: Migration From Dekstop to Mobile
Services
Mobile App
Client
Jepreto.com
Year
My Roles
UI/UX Designer
Duration
+ 2 Weeks
Project Overview
Impact / Metric: I developed both an Android photo booth operator app as well as a guest self-service photo booth kiosk, which covers over 100 screens/states, from login through to printing. User testing using 3-5 users for usability will take place right after the launch.
Jepreto creates self-service photobooth software for use by independent studios in Indonesia. For the desktop version, the session launches immediately upon opening the application. However, for the Android version, the task at hand is quite different because operators go from one wedding or public event to another, with every single event requiring configuration prior to the first guest taking pictures.
That means that there will be two very different persons using a single tablet: an operator who has little time to configure the photo booth, and a guest who only has one opportunity and will never read any instructions.
The Problem
Initial Assumption:
The mobile application would be a reduced version of the desktop application: start a session, take pictures, print.
The Problem:
The kickoff process proved me wrong. Operators personalize each event, which means setup is first, and the application must make it fast. Printers are usually connected through a laptop, not through the tablet itself, making for one extra handoff step, which most competitors fail at.
I also looked at three different booth applications and their customer feedbacks. The problems mentioned in the reviews were never about lack of functionality, but lack of clear information: a printer process failing without a message, a "share" button being difficult to locate, an application crashing and no message, setup process confusing new users.
The problem wasn't really "what does the application do?" It was rather "is the person using it always aware of what to do next, and what just happened?".
Discovery Insights:
Insight 1 (One Chance): The guest uses the booth only once, so there is no learning curve to fall back on. Each mistake made is a failure.
Insight 2 (Readiness): Most failures happen before the guest gets there, like the printer being down, the camera unplugged, or the storage being full. Operators only know after it happens.
Design Decisions:
"One Screen for 'Which Event' and 'Is the Booth Ready?'"
Why: System Status Visibility and Progressive Disclosure. An operator opens the app and asks herself these two questions: what event am I running; and do I get started? Thus, I placed event banner above the live cards, which tell about the status of camera, printer and storage with date of last check and actions.
Benefit: All problems get solved prior to guests arriving, and there are few taps needed prior to the first session.
"Failure State Screens as First-Class Screens"
Why: Error Recovery. The 'Start Booth' button remains inactive with a simple message on why it can't be done. Payment timeout; invalid voucher; no connection to device or print failures — all get a subsequent step.
Benefit: Operators can recover easily in front of a queue of guests.
Web Dashboard Is the Truth Source
Why: The templates and prices are stored in the Jepreto web dashboard. The app is reading the information from it, and it will use the last synced data with a not synced badge when offline. The lesson from my previous experience with Jepreto: duplicating setting paths leads to confusion.
Benefit: The configuration by an operator is the same that guests see, and there are fewer screens to manage in the app.
Onboarding That Makes a Difference
Why: Short questionnaire determines either Beginner or Experienced mode. For beginners, there will be a "Start here" checklist which will disappear after finishing. Experienced operators go directly to the home screen. I kept only those questions which affect the app behavior.
Benefit: Beginners go through onboarding process faster and never slow down returning operators. (Flow designed; screens still in progress.)
Outcome
There are no metrics on the app at the moment, since it is not up and running yet, and I would prefer not to make any up.
Current status: sitemap and user flows for both modes, low fidelity wireframes, and high fidelity 100+ screens and states. It includes the operator setup wizard, events and devices management, and the guest flow of payment, capture, review, edit and completion, with all failure states for payment and sign-in. The prototype and handover are the next milestone.
The next step is validation. In two weeks after the release, I will hold a usability session with 3–5 operators and guests, and update this page with my findings.
Reflection
Note About Scope
This project is confined to researching and designing interfaces exclusively; backend development is out of its scope. Managing templates and pricing will continue being performed using the website control panel. Features like studio mode or various AI capabilities were intentionally left for a later step. The problems detected during the course of work, belonging to developers' responsibilities, have been documented and transferred over to them.
There are certain details that are yet to be worked out in prototyping stage, such as the settings of idle time-out and a few boundary conditions.
Reflection
The first big surprise came at the halfway point. I realized that the templates and the pricing information were already living on a web dashboard, whereas my first draft assumed that the operators would construct everything within the app itself. With the app becoming a tool for selection and validation rather than creation, a bunch of screens fell off, and the rest became simpler. Now, before drawing any screen, I start with an understanding of where the source of truth lives.
The second lesson learned came from the competitor reviews. The customers didn't want more functionality; they wanted information about what was going on. Most of the design effort ended up being screens that are not shown in portfolios: errors, loading, and recovery.
The question that remains to be answered is whether the onboarding questionnaire is worth it. I believe it is, but I'll find out from the post-launch interviews.
