Skip to main content
HomeWriting
Aikakone

Earlier case study

Map-Based Citizen Feedback for Bus Passengers

How a competition brief became a map-based feedback flow that kept the task simple enough for a fast MVP.

map
Earlier case study

A civic service concept that tied citizen feedback to location and kept the flow simple enough to evaluate as a competition MVP.

What this case proves: I can keep a civic concept understandable, buildable, and testable under tight competition constraints without overstating the result.
My role
  • Service design
  • Interaction design
  • UI design
  • HTML/CSS layout support
Team
  • 1 designer
  • 1 developer
Timeline

April 2017 to June 2017

Context

Living Lab Bus student software competition for a web app that would benefit bus passengers.

Problem

Problem type: civic feedback routing and map-based browsing for location-specific comments.

Users
  • Bus passengers
  • Residents who submit feedback
  • Officials and the public who read the map
Business context

The brief required something original, web-based, and built with the LLB Developer Kit and portal.

Constraints
  • Schedule was tight
  • The team had to work with available API options
  • The project needed a quick path from sketch to MVP
Discovery
  • Use case description
  • API exploration
  • Pencil drafts
  • Heuristic evaluation
Key insights
  • Task clarity matters more than visual detail when the flow is short.
  • Users need to know the status of what they submit.
  • Navigation should make the next step obvious.
Concept model

A map-based comment service that ties each comment to a location.

Key decisions
  • Show task, status, and next action clearly.
  • Use a lightweight flow from comment to map.
  • Keep the representation simple enough for competition timing.
Design details
  • Quick pencil drafts
  • Pixelmator UI mockup
  • Material Design color cues
  • Use case description
Implementation support

I worked on the HTML, React, and CSS layout while the developer set up the Heroku backend CRUD API.

Hard metrics

No adoption, official-use, or long-term service metrics are documented for this competition MVP.

Qualitative evidence

The heuristic review identified clear status visibility, back navigation, and consistent screen structure, while also naming missing error handling and help documentation.

Proxy evidence

The competition entry received part of the prize, which suggests the concept and implementation were strong enough for the jury to recognize under competition constraints.

Reflection

A useful archive example of implementation support under competition constraints, but not a claim of production adoption.

My role

I handled the service, interaction, and UI framing: use case, pencil drafts, Pixelmator mockups, screen flow, and heuristic evaluation. I also worked on the HTML, React, and CSS layout, while the developer set up the Heroku backend and CRUD API. The MVP and competition result were team output.

Problem

The brief asked for something original, web-based, and useful to bus passengers, but the real design challenge was turning scattered civic comments into a clear task that people would actually finish.

Solution

Kiva Kaupunki collected user input tied to location and visualized it on a map so residents, officials, and the public could read place-based feedback in one place.

Process

The project was condensed, so the work focused on a clear use case, a lightweight flow, and a fast path from sketch to MVP.

    0 step
  • Research
    • Ideation
  • 1 step
  • Design
    • Use Case
    • Sketches
    • Mockups
  • 2 step
  • MVP
    • Back-end
    • Front-end
    • Deployment
  • 3 step
  • Evaluation
    • Heuristics

Research

The first question was what could realistically be built in the time available. We browsed APIs on avoindata.fi looking for something related to public transport, but the options were limited and Pasi had already worked with most of them.

We found an existing pattern worth adapting: services that let citizens tag location-based comments so planning officials could see what residents actually noticed about their city. That felt like the right fit for the LLB audience, so I suggested we build our own version of it.

Design

The design priority was clarity: what the user is doing right now, where they are in the flow, and what comes next. I wrote a use case description to work out which screens were actually needed, then sketched them quickly in pencil with the focus on available interactions.

See Use Case Description

USE CASE DESCRIPTION

A woman steps on a bus on her way to Hatanpää arboretum. She intends to enjoy the sight of beautiful flowers and read a book by the lake. During the bus ride, she sees a little girl crossing the road on a crossing. The girl manages to cross the road but it looks like she feared high traffic. Woman thinks that something should be done to make this specific crossing safer as she also has felt unsafe crossing it on her dog walks. Instead of passing on this thought she decides to do something about it as there is now an easy way to act. She goes home screen in her smartphone and touches the living lab buss icon, now she selects Kiva Kaupunki from the main screen of the application. She selects the crossing location on the app, selects the topic of "Difficult to walk on foot" and goes on to write a comment about the crossing. Application announces that the comment has been saved and will be available soon on the map. The woman continues her journey to location and decides to share also a comment on about arboretum on arriving there, as it is one of her favorite places to visit.

User Interface Design

I moved the sketches into a higher-fidelity mockup in Pixelmator. Visual style followed Material Design and the LLB color guidelines.

My mockups of the screens of the application

Minimum Viable Product

The plan was to collect data of location, subject and a comment and make a map data visualization when sufficient data has been collected and then possibly pushing out an update for the users to inspect the map.

Pasi established Heroku backend with a very basic CRUD API, with POST adding, GET getting all and id:GET getting a unique entry. It can be confirmed here that the api has a location, topic and a comment.

We built in React — Pasi's comfort zone. I handled the HTML layout and CSS to match the mockup. With the deadline close, we worked through the remaining issues together and submitted through the LLB Developer Portal.

Evaluation

I conducted heuristic usability analysis, based on Jakob Nielsen's 10 general principles for interaction design, to evaluate the MVP.

The review found a few practical strengths: the current state was visible through headings and the top-right indicator, back navigation was available, and the screens followed a consistent structure. It also made the limits clear. Error messages, help, and documentation were missing, so the MVP was useful as a competition prototype rather than as a complete public-service workflow.

Conclusion

"With different pros and cons the jury found on multiple apps, the jury chairman decided to divide the first prize between the three teams. Thus, each team will receive 200 € and a diploma."

The entry received part of the prize, but that is only proxy evidence. It says the concept and prototype were credible in the competition setting, not that the service was adopted or used by city officials.

The more durable lesson was about ownership. The concept moved from use case to interface to implementation support, but the compressed schedule made coordination fragile. If I were doing the same work again, I would define ownership and decision rhythm earlier instead of treating scheduling as a side task.

Links

Github
Pasi Kuparinen

Next Project

Concept service for memory care

Aikakone

Field research, service blueprinting, and facilitated prototype sessions explored what families, staff, and residents would need to trust.

Concept work