João BatistaProduct Designer

MAIN

WorkInfo

CONTACT

LinkedIn Email Resume
    SELECTED WORK

    Drivo

    Luxury car rental

    Renting should feel like the car: quick and premium.

    CASE 03 / CONCEPT / 2024
    DRIVO / RENTAL APP IOS / SELF-INITIATED CONCEPT
    MY ROLE
    Product DesignerConcept, IA, interaction design, UI, component library
    SCOPE
    Full appEntry, sign up, catalogue, booking, payment, rentals, profile
    TYPE
    Self-initiated conceptNo client and no brief. Built to take one flow all the way.
    STATUS
    CONCEPT · 2024

    01 OVERVIEW

    A rental app taken from the first screen to the invoice.

    Drivo is a concept I set myself: renting a high end car from a phone, end to end. Not a few pretty screens, but the whole product, including the parts portfolios usually skip: account creation, password recovery, empty and error states, the booking form, payment, the rental in progress and what happens after it ends.

    The car leads

    Photography carries the product. The interface stays out of the way.

    One flow, no gaps

    Every state in the journey has a screen, including the awkward ones.

    Money in plain sight

    Daily rate, number of days and total stay visible through checkout.

    02 CHALLENGE

    Desire sells the car. Detail closes the rental.

    Specs get in the way

    Rental listings open with a table. The reason someone picks this car is never in the table.

    Trust breaks at payment

    Four figure amounts, an unfamiliar brand and a car someone else will hand over in person.

    HOW MIGHT WE

    hold the feeling of a premium car through a flow that ends in a large payment and a stranger delivering the keys?

    03 BROWSE

    Arrive wanting it, then find out what it does.

    The entry screen is one car, one line and one button. The catalogue then does the hard part: brand shortcuts, category pills and a filter, with each card carrying the rating, the model and the daily price on the car's own colour.

    One car, one promise, one button.

    04 BOOK AND PAY

    Three questions, then the money.

    Booking asks only for dates, pick up and drop off, on a map that keeps the car in view. Payment repeats the order, the daily rate, the number of days and the total, so the last screen confirms rather than surprises.

    Days, pick up and drop off, with the car sitting on the map.

    05 AFTER THE TRIP

    The product does not end at the payment.

    A rental in progress shows who is delivering the car and how to reach them, the dates, the two addresses and the status, then asks for a rating and offers the same car again. The profile keeps it light: two numbers, four links and a way out.

    The driver, the status, the dates and the addresses, then the review and a way to book again.

    06 STATES

    The screens nobody puts in a portfolio.

    A rental app is mostly made of these: a brand with nothing available today, a list you saved for later, the notifications that carry the operational truth, the picker that gets you to a brand in one tap. Drawing them is what turned a set of screens into a product.

    Eight brands on a dark grid, one tap away from the catalogue.

    07 DESIGN NOTES

    Four decisions that hold the app together.

    1. D.01Dark stageNear black backgrounds so the cars carry the colour.
    2. D.02One amber actionA single warm button marks the way forward on every screen.
    3. D.03Cards coloured by carThe catalogue reads as a garage, not as a list.
    4. D.04Light where trust mattersAccount, booking and payment move to light for legibility.

    What the concept taught me.

    Almost every improvement came from taking something out: fewer specs, fewer buttons, fewer colours, until each screen had one thing to look at and one thing to do.

    The part that made it feel like a product, though, was the opposite: drawing the unglamorous screens until the flow had no gaps.