How several days of prototyping and 3 ethnographic interviews saved weeks of development
Everybody knows that digital products should fit the needs of their users, right? Nevertheless, many teams are tempted to skip the research and early user feedback gathering in favour of faster development. But is it really faster?
Parkanizer for short time parking zones
A pilot of the innovative Parkanizer Parking Information System had already been introduced in one city, Piekary Śląskie. It utilised sensors located on parking spots to detect which are occupied and showed this information in a mobile app for drivers. The system also included a web panel with useful parking statistics for the municipality. That was our starting point.
In Tarnowskie Góry – another city where Parkanizer was to be introduced, we were met with an additional challenge. Parkanizer’s task was not only to inform drivers where to find a vacant parking spot, but also to support the city in introducing a short-term parking zone, and help them to enforce and control it.
At the beginning, both the municipalities and us assumed that for the control purpose it would be best to develop a mobile app dedicated for city guards. We planned for it to be used on small tablets by the patrols – to enable checking in-field if a certain car is exceeding the 90 minute time limit for parking. When the car park infrastructure was already in place, it was high time to start developing the solution for city guards. And the last call to verify if our assumptions were right.
Challenge: to support Tarnowskie Góry by introducing a short-term parking zone and helping with its enforcement and control
Assumptions: it is best to develop a mobile app for city guards to be used on small tablets during their patrols
Assumptions test: 1 interactive mock-up prepared in Axure + 3 ethnographic interviews and usability tests with city guards (7 man-days)
- setting a special analytical dashboard in an existing Parkanizer Analytics in-browser application instead of developing a user-unfriendly mobile app
- saving approx. 20 man-days of development
- diagnosing extra risks & coming up with an idea for product launch communication in the city
Making the tough, but right decision – stopping the development to test assumptions
Developers were ready to start coding right away, but two people from the UX team were strongly opposed to basing the design only on information from city officials. Our UX Designer, Marta, and I insisted on contacting the final users of the application – city guards who would be responsible for enforcing the new parking regulations.
User tests would take several additional days, and we all felt that our small team was running out of time, but I had already conducted some desk research on the topic and we became aware that there was a long list of questions about the city guards’ work which we did not know the answers to. The team sat down together to discuss them and the Project Manager of Parkanizer, Maciek Lukas, made the right decision and gave me several days to organize and conduct research.
Researching in the field – listen, observe, and understand
At this point, it was possible to meet with 3 people: the Chief of City Guards in Tarnowskie Góry, another city guard, and the municipal officer responsible for the whole project of introducing a short-term parking zone. I took a short walk around the city center with them to see where the zone was to be introduced – it was a great chance to learn what the guards’ everyday tasks and challenges look like.
Then a 1-hour interview took place. Thanks to both the interview AND the walk, I gained a fairly clear vision:
- that there are very few city guards in Tarnowskie Góry, while at the same time the city is quite spread out
- what the shifts look like, and that there are only 2-3 patrol groups per shift
- what the range of city guards’ tasks is, and that controlling the parking zone will only be one of many tasks
- what the office looks like and what kind of computer and other equipment is at their disposal (quite an old-school one)
- what the process of fining incorrect parking looks like
- how the guards report their work and what measures will be useful for them
It was equally important to meet the city guards in person and get an idea who we were designing for. I had the chance to discuss the city guards’ expectations and challenges connected with introducing a short-term parking zone and our system with the Chief of City Guards. I discovered that it still was not clear how the zone will operate and how the drivers and city dwellers will react to new regulations. The question of reliable data about parking time was especially important, since nobody likes to get fined, and many people had already been hostile towards city guards in the past.
I prepared a report summarizing all the findings, including photos from the field, to show the whole team the context in which our solution would be used. It became a source of important arguments when making decisions on many issues from then on.
Easier said than done
Even though this first interview left us with some hints that the mobile application is not the best solution for the city guards (e.g. they were already handling a lot of heavy equipment and using a tablet in the field would not be handy), we were too biased to understand their importance.
That is why our UX Designer sat down and – using the information from the report – sketched quick mock-ups for a mobile app. We all wanted to get back to the guards with it and check how it works for them as soon as possible. We decided to use an Axure mobile app and Unlimited Screen Recorder to conduct and record a usability test.
The ultimate answer
We arrived in Tarnowskie Góry on a gloomy September morning. There were two city guards waiting for us at the office – one who was an experienced dispatch, and the other who usually worked in the field. They happened to have extremely different experiences with mobile technologies and mobile applications, and of course the realms of their everyday job differed heavily. That was the best scenario we could dream of.
Nevertheless, after 2 individual interviews and usability tests, as well as a follow up discussion, it became apparent that the mobile application we designed was too elaborate, and that the guards would far more appreciate… an in‑browser panel that would be operated by a dispatch. It was enough for a dispatch to get notified by Parkanizer when somebody exceeds the 90-minute parking limit so he could send the closest patrol there – as long as it was the most important issue for the city guards at the moment!
There were several other functionalities to be kept or changed, but the most important conclusions were very optimistic for us – instead of developing a totally new complex application, we could just reshape an existing analytic panel to communicate exactly what the new users needed.
Stop wasting time
We learned several valuable lessons thanks to Maciek’s decision to let us gather as much information about users as possible before we started developing the product, even though the deadline was approaching:
- it is cheaper and faster to work smartly than start development as soon as possible. By investing some time in user and context research, we saved weeks of development and in fact finished the solution faster than we planned.
- you should try to become a partner for your users. It is very important to build a connection and communication channel with them in order to understand their challenges. They will pay you back with engagement in your product and become eager to share feedback when needed. They are also more forgiving for imperfections in the first versions of the solution ;-)
- do not concentrate on your product only – try to look at it as part of the context. Thanks to that you will have a real positive influence on people’s everyday lives. And this is very satisfactory for the whole team.
During the interviews we noticed several times that even though the city officials and city guards were pretty sure that the introduction of a short-term parking zone was the right decision, they were worried about the negative reactions of the drivers. That was worth initiating a discussion!
We agreed on an idea to start “soft” – not with fining the drivers, but with education in the form of “karny pyrlik”. This funny leaflet, together with other information materials, reminded the drivers about the new rules, the benefits of introducing the parking time limit, as well as the possible consequences of exceeding the parking time in the future. After all, the drivers, city dwellers, and local business people were to become the users of the short-term parking zone and Parkanizer. And the 3 aforementioned rules apply to them as well :-)