iRent — Self-service rental redesign

Overview

Project context

iRent is a self-service vehicle-rental app in Taiwan.

Role and ownership

Personal redesign based on my own use of selected functions; this is not an official iRent project.

Team and collaborators

Independent project.

Timeline and product stage

Concept redesign documented in 2020.

Primary constraint

The work focuses on UI presentation. It does not include demographic or behavioral research beyond my own usage and assumes that the problems I encountered may represent similar occasional users.

I used iRent about once or twice a month for short trips within Tainan, usually under 30 minutes. My typical journey covered finding and reserving a vehicle, pickup, startup, opening the trunk for a helmet, driving, stopping, and returning it.

Problem evidence

Three moments of uncertainty

1. Choosing a vehicle in a dense area

At stations and other high-density parking areas, overlapping map pins made it difficult to compare vehicles or identify one positioned near the edge of a crowded lot. The physical parking environment and the original map both show why a single selected pin did not provide enough spatial context.

2. Starting an unfamiliar vehicle

Different fuel and electric models use different startup methods. Because I rented infrequently, I sometimes had to search online or ask someone nearby before I could start an unfamiliar model.

3. Knowing whether a remote action worked

Remote vehicle controls depend on the network. When feedback was delayed, I could not tell whether the command had been received and tapped again. The original interface also handled action and status inconsistently: the startup control changed with vehicle state, while the trunk control did not communicate state in the same way.

Making the startup state explicit

I mapped the handoff between the app and the vehicle: pick up the vehicle in the app, send the startup command, confirm that the vehicle has powered on, then continue with the physical controls.

Prototype comparison

I tested two prototypes with two participants who had similar iRent usage habits and asked them to think aloud.

In prototype 1, both participants were confused by the label “188.”
In prototype 2, I replaced the ambiguous status with “Power On” so the system state was explicit.

Solution

Clearer remote-control hierarchy

The revised skeleton separates the vehicle’s off, connecting, powered-on, instruction, ready, and driving states. Terminology and button hierarchy were adjusted so that the interface communicates both the requested action and the current vehicle status.

Easier vehicle comparison

For dense clusters, the search interface uses a horizontal vehicle selector. This keeps the surrounding map visible while letting users compare nearby vehicles one at a time.

Final visual delivery

The final UI uses a dashboard-inspired visual language, a restrained red and navy palette, explicit status labels, and consistent vehicle controls across the search and startup flows.

Learnings and limitations

This concept shows how explicit system status, model-specific guidance, and focused comparison can reduce uncertainty in a self-service journey. The evidence is limited to my own experience and two participants with similar usage habits; no production or business impact was measured.