Cyclaport
Overview
What is it?
A web based platform accessible on mobile and laptop that enables the cyclists of Brussels to report issues they encounter on their cycle and also see previously reported issues.
Skills used
Remote and in-person testing and data collection
Ethical data collection processes
Data analysis
Literature and commercial research
UI and Graphic Design
Wireframing and Prototyping
Agile sprints and iterative process
Figma, Weavely, Microsoft Forms, UXTweak
Presentation of work
Timeline
2024
6 - 7 months
Solo project
Sole designer and
project manager
Problem statement
Cyclists feel like an afterthought in urban planning in Brussels even whilst the city is trying to transition into a more bike friendly city. There are no obvious ways to give feedback directly to the relevant urban planning authorities which only make cyclists feel even more disempowered. This is a problem because cyclists are the first and most important users of the cycling infrastructure in the city and could provide the most valuable insight into how it is actually being used, if they are not included in the conversation of transitioning to a more cycle-friendly city, Brussels may lose the very target group they are trying to incentivise.
User Research
I started my user research with a survey of urban cyclists in general to understand what made them happy and what made them frustrated when cycling through cities, I coupled this with some online ethnographic research on Reddit to see what people were complaining about as a whole.
​
Some of the survey insights
Online ethnographic research surrounding cycling
Insights specific to Brussels
I got a first general understanding of the issues the cyclists encounter but I also got a feeling for something deeper – that cyclists felt most seen and encouraged to cycle in cities where they felt listened to and catered to.
​
Relating to Brussels’s cyclists specifically, they would want to reach out to the government to report an issue but there was no obvious way of going about doing that.
INSIGHT
With my survey answers I was able to build two personas, a primary and secondary one that I would keep as my reference as I got into the first round of iterations.
Primary Persona - Lin Marie Van de Poel
Secondary Persona - Brecht Raymarckx
Market Research
User research revealed that cyclists were not sure where to go to report an issue so I wanted to look at what was available to cyclists in Brussels. It could be that all that was needed was an information link between cyclists and resource but there could also be a useful gap.
​
I experimented with the public bike sharing schemes, Dott, Lime, Voi and Brussel’s own Villo. None allow cyclists to give feedback on the urban infrastructure but focus on the experience of using the service. There is also Floya, Brussel’s city-backed multi-modal transport solution that shows all possible transport methods to get from A to B and therefore also includes people travelling on their private cycles – but this also did not allow for feedback on the city or the experience of moving through it. Especially with regards to Floya and Villo, these feel like missed opportunities.
​
I also looked into citizen reporting tools available to citizens of Brussels in general and conducted a feature analysis to understand what made them work or not. I looked at Ping, Bike Citizens, Bike Barometre (research from KU Leuven), Telraam, Fixmystreet Brussels, BikeMaps and Bikemap.
INSIGHT
For the cyclists of Brussels, there are no clear ways on how to even engage with the city so that they could have a chance at a conversation.
On top of that, the tool they use must be flexible, easy to use, open to all and designed for cyclists specifically so that it does not force them to behave in ways that are unnatural to cyclists.
Prototyping
Early prototypes
I started with paper prototypes converted into clickable prototypes, they were easily shared so that I could build up quickly and iteratively to more complex prototypes. Every iteration was tested directly with the cyclists with direct observation and follow up interviews, the data was mapped and understood through affinity mapping to generate insights and next steps.
I started off by building the mobile version of this platform as this solution was designed to be used safely, and for it to be as portable as possible. The quicker a cyclist could report a problem, the clearer the details would be for them.
INSIGHTS FROM EARLY PROTOYPES
Cyclists wanted reassurance of who was behind the portal, how their data would be used and what kind of follow up would come from their report.
​
Recalling the issue meant that cyclists not only responded emotionally (they all skipped over the map feature at first to say what had happened and failed to fill this important information in) but 80% also said that the locations they were reporting were approximate and not precise. The reporting form was useful but needed to be designed to reflect how people recalled the information.
​
There were also concerns around remembering to use the portal or even knowing about its existence which told me that having the platform available where cyclists need it and see it was important.
Card sort exercise
Accompanying these early iterations I also ran a card-sorting exercise.
These help uncover the logic that cyclists apply when grouping together the issues they encounter on the road so that the information architecture of Cyclaport can be as intuitive as possible for the cyclists. The issues used in the card sort were generated from the user research.
INSIGHTS FROM CARD SORT
Three main categories of issues arose: when someone else’s behaviour causes an issue, poor road condition and infrastructure problems.
​
Also, some issues could appear across several categories because they could arise in different contexts (eg. a car parked on the cycle lane could be a behavioural problem as well as an issue with road obstruction) and where that made sense, I allowed for the issue to appear in more than one category so that the cyclist would always find it.
Mid fidelity prototype
Sample screens of this iteration
INSIGHTS FROM MID FIDELITY PROTOTYPE
There was a lack of clarity around how the data would be used, even though the information was included in this prototype only 50% of cyclists saw it, and even then they wondered how quickly they would get a response from the platform or the government. They also wanted to see what other reports had already been sent through. This lead to a lack of trust in general in using the platform - unless they knew it achieved something they would not want to use it which undermined the whole point of the platform: to allow cyclists to be listened to.
These tests also revealed an expectation shift in the cyclists: they wanted their reports to lead to quick fixes of urgent issues (eg. debris on the cycle lane), not just long-term improvements.
Creating a form that flowed with how cyclists responded to remembering an event worked well but 75% of cyclists were frustrated at having to switch between issue categories to find the best option to describe their problem. This friction could lead to not wanting to use the platform in the first place so this needed addressing.
High fidelity prototypes - Final version
From here I moved on to high fidelity prototypes. These now had the branding and design applied to them which I developed through brainstorming and research into other transport-related public facing offerings on behalf of Brussels such as Floya, STIB/MIVB and Bruxelles Mobilité / Brussel Mobiliteit.
​
As of this version, the platform also included a new feature: a live map that showed previous and current issues that had been reported and the solutions chosen to fix them.
​
This version then saw its expansion into French and Dutch as they are the official languages of Brussels and public facing services are always available in those languages.
​
Finally, this was the point at which I built out the website version of the platform, by applying the same content developed thus far to the logic of a website.
​
Sample images of first high fidelity prototype
All this led to this final prototype.
​
Final prototype sample images mobile and browser versions
INSIGHTS FROM 1st HIFI PROTOTYPE
Users trusted the platform more thanks to the map feature because it helped them see how quickly issues would be resolved and what was being done about them. In-context information about how their data was used (eg, how quickly they would get an answer to a report) also helped them understand and trust the platform.
​
Seeing that a government entity was behind the portal helped them trust that something would be done long term and feel like the city was on their side. It touched back and built upon the very first insight, that cyclists who felt listened to were also more willing to cycle and be involved in their city.
​
The cyclists wanted to stay involved with their report beyond submitting, seeing how it progressed would also renew trust in the system. Making the follow up of their report as easy as possible was therefore important.
​
There were still concerns from 40% of cyclists that they would not use the tool if they did not use it immediately, which points towards the need to put the platform where the cyclists are looking so that they use it.
Making Cyclaport findable through user research
As highlighted through the tests, if cyclists are going to use this portal then it must be available to them when they need it.
Through observation of cyclists and my initial user research I identified many entry-points for cyclists: local government websites, the Brussels bike scheme Villo, Brussel’s multi-modal mobility app Floya, advertisement at public transport stops as cyclists often cycle to a stop and then commute onwards by public transport and advertisements near public cycling infrastructure. To build long-term trust, ongoing engagement through social media, email follow-ups, and local advertisements is essential.
​
A flow of user entry points and continued use of Cyclaport
I also created some mock ups of what advertisements in targeted locations may look like.
​
Sample of targeted marketing mock ups
Setbacks and challenges
A main challenge of this project was learning to work with participants effectively, I had trouble with my communication style at first and was struggling to get participant involvement. The communication was flowing entirely one way from me to them and that did not encourage cyclists to get involved with the project, but once I entered into more of a conversation with the cyclists then everything flowed more smoothly.
It was also a challenge to be working with new technology, Weavely, and finding ways to incorporate it effectively within what I already know: Figma. I am not one to shy away from a technical challenge and have learnt to use new software as a result but can recognise that with a wider team and a software engineer some areas of development may have moved a lot faster.
Not all the remote testing I carried out was appropriate. The survey and the card sort work well as unmoderated remote tests but my very first prototype test was also designed like that and it was the wrong call. Even though I got answers they lacked depth and I kept wanting to ask “Why?” to all my participants. I’m glad I tried something new but even gladder to learn that it isn’t appropriate for this kind of early prototyping.
​
Working alone on a project for so many months also requires a certain degree of courage and resilience – at times, I was the only one to believe in it and see it through. As I prototyped and showed the project to more and more cyclists, I had the satisfaction of being proven right in my insights and building something that they truly found useful.
Takeaways
Working with the users from as early as possible and throughout the project made it what it is, and finding ways to work better with them made all the difference when it was hard to get their engagement at the beginning. It is always worth finding the way to have contact with your users as they will point the way.
​
Also, my initial understanding that the way forwards was to make the cyclists feel heard was bang on – much of the project then revolved around the best way to accomplish that. This tells me that I can derive useful insight and it is worth exploring. This platform was something that excited every single cyclist that tried it, they often asked if it was real and this more than anything told me that I was building something useful for them.