
Aikakone
Field research, service blueprinting, and facilitated prototype sessions explored what families, staff, and residents would need to trust.
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.
"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.