Twyns

An app for municipal law enforcers which aids them in the field. With an accompanying desktop portion for management.

Metadata

February 2022 – 20 weeks

Graduation Project

Worked with a product owner and a developer as a 3 man team

Introduction

When I started at Twyns, they already had a product which they had placed in the market. This product was called Parkius, which as the name might suggest, is software that helps you to manage parking. This software is specifically made and sold to municipalities like Rotterdam and Antwerp. 

Because of this first product, there is a lot of contact between Twyns and the municipalities that rely on their product to manage parking. As such, the municipalities approached Twyns with the request for additional products. Twyns set up a small team with the aim of creating a new product, this time not for parking but for aiding local law enforcement personnel. 

 

My sole focus during the 20 weeks I spent at Twyns was to design this new solution. It would be sold to municipalities but it would be used by the law enforcement personnel that they employ.

 

Challenge

Designing something new, more or less from the ground up, was a large part of what made this project challenging. Sure, Twyns already had a different product, but this new solution was supposed to be a separate thing. For instance, the request was to come up with a completely new visual style. The end-users were the same but the workflow which we would help them with was very different. The previous product focused solely on parking. This time, we would look at the entirety of an enforcers workflow.

 

A lot of time and effort went into learning all about the end-users. What kind of work do they do? What are their responsibilities? What kind of structure do they have that helps them do their jobs? The most challenging part of this project had to do with getting access to these end-users. Enforcers are busy people and their management proved to be very hesitant to let outsiders like me anywhere near them. As a result, way too much time went by without me having proper access to the people for which I was designing this solution, which negatively impacted the quality of the end result. 

 

Another part of the challenge was managing time and meeting deadlines. A graduation project only allows for 20 weeks to be used from start to finish. This meant the team and I had to make some decisions regarding scoping: What are some features that the users are going to really love, and which are nice to have but maybe not as essential for a first version?

 

Objective

Create a new solution that helps municipal enforcers do their work, both for the enforcers in the field as well as for the personnel managing everything in the office. 

 

In the end, I ended up spending 20 weeks doing just that. If you’re interested in following along with the entire process, then feel free to read on. If you’re short on time, I would recommend checking out the figma prototype and the figma design file. If you want even more content, then I would recommend checking out the graduation dossier I made.

Researching the problem space

According to the dutch central government, there are roughly 23 thousand enforcers employed in the Netherlands. These are spread out over 6 different domains. The most common domain is that of the municipal enforcer, which is the one we will be focusing on for this project. A large group of people, all of whom are in uniform, but they are not exactly uniform. In order to learn more about this group of users, I would have to do research. My goals were as follows:

Research goals

– Organization analysis: How do enforcers and their management operate now? What is the organizational context like?

 

– Competitive analysis & business goals: Are there competing software providers? If so, what do they do? Is there anything to learn from that? What kind of functionality do they offer? What is Twyns’ unique selling point? Why will a municipality choose Twyns and not another provider? What does Twyns want to achieve? How long can that take? Where will we be in 2 years? What accessibility standards do we adhere to when creating the design? What is the emphasis on?

 

– User analysis: What are enforcers like? What are their responsibilities? Under what conditions do they work? What are the user needs? What is expected of enforcers from their employer? What are some features that might be useful for this group of users?

 

Research methods

 

In order to gain insights, I would be using various methods. I started off by doing desk research. I tried to learn as much as I could from the internet about municipal enforcers as I could. Then, to confirm my findings, I did an interview with an actual enforcer, to figure out if there were any disparaties, and also to clear things up that weren’t clear. These two methods were there to complete my first goal, which was to do an organizational analysis.

 

After analysing the organizational structure of enforcers, it was time to learn more about the competition, as well as what Twyns’ goals were. I employed desk research to learn more about the competition, because getting an interview with an enforcer who was familiair with a competing product proved to be impossible. After about the competition, I could come up with various question which I could ask the product owner during our interview.

 

Finally it was time for the user analysis. In order to do this, I opted to follow along with actual enforcers in the field for a day. Mainly observing what exactly it was that they were doing. This proved to be key in really understanding what it was like, as opposed to merely reading and asking and then filling in the gaps in my mind.

Research insights

 

Familiar structure

Enforcers start their day with a daily briefing session, almost like a daily stand-up which you might find in tech. Management presents a powerpoint in which they draw attention to certain things that need it.

Enforcement happens as a team, over time

Enforcers go out on patrols in pairs. They might be in different neighbourhoods depending on the day, but they tend not to leave their assigned municipality unless there’s a big event somewhere nearby.

Enforcers are relatively young

I met about 10 enforcers during this project and most of them were between the ages of 20 to 40. Some of them don’t look a day over 20, because they focus a lot on their physical health.

Tasks include:

Issuing tickets, registering information, detaining wanted individuals, talking to civilians, responding to emergencies, surveying hotspots and checking if people have paid for their public parking spot.

Information is key

Information from citizens, agencies or other enforcers is key in ensuring enforcers perform the right actions. Younger enforcers love to jump into action, but knowing the whole story leads to the best outcomes.

Enforcement happens anywhere, at any time

From dealing with petty crime in urban areas during the day, to discovering and disposing of drug waste in remote regions at night, enforcers might be needed anywhere, at any time. 

Communication, documentation and prioritization

It’s all about knowing where your colleagues are, documenting what decisions you’ve made and prioritizing between the various reports that come into the office.

Modern technology, made accessible

From desktops and databases, to smartphones and car infotainment systems, enforcers are quite proficient with modern technology. Adding a smartphone app is a logical next step, which really adds to their arsenal.

Adding details prevents mistakes

Not every municipality has the same laws, yet enforcers need to be deployable across the country. Adding a short overview of the current laws which are in effect is one way to prevent mistakes.

In the field and in the office

Prioritization happens by management, in the office. They need a modern, digital solution which they can use to prepare briefings and send updates to enforcement personell in the field.