GachaBot

Context

What do you do with unexpected free time in Kyoto?

The problem was not a shortage of recommendations. It was finding something local, timely, and a little surprising without sorting through another generic list. The hackathon took place at Kyoto Institute of Technology as the final event of Kyoto Startup Summer School.

Kyoto Institute of Technology · Kyoto Startup Summer School · the setting for the 48-hour hackathon

Field research

Start with tourists in the actual context

We went to Kyoto Station, Nishiki Market, and tourist-information locations, where unplanned time and travel decisions naturally arose. We spoke with approximately 12 tourists, some individually and some in groups. These were intercept conversations and concept-feedback interactions, not usability tests.

Team debrief after field conversations

Synthesis and affinity grouping

Simulating the experience

Make the idea tangible before building the machine

After explaining the concept without steering tourists toward a positive response, we walked them through a low-fidelity simulation. They answered questions, rolled a large die to represent the random gacha interaction, received a capsule, opened its paper recommendation, and then discussed their reaction. The simple props let people experience the sequence rather than react to an abstract pitch.

These responses were directional, not evidence of broad demand. They supported the premise that some tourists welcomed a playful way to encounter something they had not already searched for. Participants also made the need for useful description and navigation information clear.

Interaction model

Ask only for information that changes the recommendation

We proposed three questions about available time and group composition. Field conversations reinforced that whether children were present could materially change a useful recommendation. The team adopted 30 seconds as a design target for the interaction, so every question had to earn its place.

A clickable Axure demonstration represented this question flow. It demonstrated the interaction model; it was not connected to a working recommendation engine.

The three proposed questions during the working session

Context-aware logic

Use context to reduce what tourists must enter

The future system model combined tourists’ answers with location, weather, traffic, date, and time. Those contextual inputs could prevent recommendations that were closed, unsuitable for the weather, or impractical to reach. The hackathon prototype demonstrated this logic; it did not connect to live environmental data or generate recommendations automatically.

Rapid prototyping

From simulated interaction to physical demonstration

Once the question flow and output had taken shape, the team built a physical form for the final pitch. The recommendation slip also evolved from a handwritten prop into a fuller concept with a photo, description, directions, and a QR code.

Building the physical hackathon demonstration—not a functioning automated recommendation machine

Recommendation slip · field simulation

Paper recommendation used to simulate the experience

Recommendation slip · final concept

Expanded concept with description and navigation information

Design rationale

Why a machine and not an app

A familiar interaction and physical presence in Japan

Gacha machines were already familiar in Japan, easy to recognize, and playful by design. A physical machine could stand at the moment the need arose—in a station or tourist-information location—without requiring someone to discover, download, and remember an app. Its random reveal also made an unexpected recommendation feel like serendipity rather than an unexplained algorithmic choice.

What this demonstrates

Four decisions that shaped GachaBot