Earlier case study
How a competition brief became a map-based feedback flow that kept the task simple enough for a fast MVP.
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.
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.
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.
The project was condensed, so the work focused on a clear use case, a lightweight flow, and a fast path from sketch to MVP.
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.
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.
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
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.
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.
The heuristic review flagged missing error messages and help as the MVP's clearest gaps. Rather than leave that as a finding, the concept examples below show two of the states the MVP skipped and how I would write them now.
Before the first report, the MVP's map was simply blank — which reads as a broken or abandoned service rather than a new one.
No results found.
No reports on this route yet. Seen something on your ride worth flagging — a rough stop, a full bus, a driver who nailed it? Tap the spot on the map to leave the first one.
Why it matters: An empty civic tool has one job: turn 'nothing here' into 'you go first.' Naming concrete report-worthy moments teaches what the tool is for at exactly the moment the user decides whether it is worth using.
'Form submitted' confirms the transaction but not the point — civic feedback feels like shouting into a void unless the product shows the report landed somewhere visible.
Your form has been submitted.
Thanks — your report is now on the map for other passengers to see. It stays attached to this stop, so patterns here become visible over time.
Why it matters: The honest promise a prototype can make is visibility, not municipal action. Showing the report living publicly on the map gives the sender proof of effect without overclaiming what the city will do.
"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.
