2013 – Akuthandboken


Akuthandboken was my thesis project done together with Anders Larm at Malmö Högskola in 2013.The project revolved around exploring how digital tools could help improve the daily workflow of patrolling police officers in Malmö as well as evaluate how various interaction design methods worked within an organization such as the police force.

Roles & methods

Field studies, interviews, personas, prototyping, android development, user testing.


During 2013, representatives from different levels within the Swedish police force gathered to discuss ways of improving the daily work of police officers. A suggestion that gained traction was the digitalization of so-called "cheat sheets" that patrolling officers (at the time of the project, maybe even still today) carry as part of their equipment. These cheat sheets consist of printed documents, mainly functioning as memory aid and checklists for common procedures.

The main issue with these documents however, was that every officer had a different dated version of them, mostly due to the reason that it was difficult to keep track of when a new version was released.

Research & interviews

To get to the core of the issue, we needed to find the people within the organization we were going to design for and hear the pain points from them in their own words.

However, to get touch with the users we ultimately were going to design for, we first needed to interview two officers higher up in the organization. Partly to learn about the background and expectations for the project, but also to gain access to our target users, the patrolling police officers.

After the initial stakeholder interviews we spoke with 10-12 patrolling police officers which was super interesting. We learned what a typical work day looks like, the different tools and methods they use daily, how the current "cheat sheets" fit into their work and some other pain points.

All this newly acquired information was documented and compared to what we learned from the officers higher up in the organization, to see if we could find any similarities or differences in their needs.

At this point we also decided to limit the amount of field studies while the officers were on duty. Partly due to the fact that dangerous situations might occur (for us and for them), but also partly due to learning that they often didn’t really use the current paper material, perhaps leaving us with not much to observe.

The interviews left us with some super interesting discoveries, but we had also promised our interviewees anonymity. So how could we convey our findings to the stakeholders higher up in the organization in order to move forward? We decided to use the interaction design method 'personas'.

Meet the personas

These weren't the tradtionally well-developed personas as perhaps Alan Cooper would have argued for, but rather a more utilitarian type of personas, which proved very useful when giving feedback to the people higher up into the organization.

The Methodist

The Methodist persona was rare among our users and actually used the cheat sheets regularly. When she couldn't find the information she was looking for in the cheat sheets, she would call a colleague or her superior. Since the Methodist was the persona that actually used the cheat sheets, she became our main target user for later when designing the prototypes.

The Improvisor

The Improvisor rarely used the cheat sheets, relying on her private smartphone instead. She called and asked colleagues for help or used third party apps like "Find my iPhone" to locate stolen smartphones.

The Distributor

The Distributor has been on the force for quite some while and knows what information is good to have, so she compiles and keeps personal cheat sheets which she shares with her peers. Rumor goes that aspirants aren't the only ones asking her for copies of her personal cheat sheets...

The Collector

The Collector persona gathers and compiles documents provided internally as well as from the Distributor. Due to the nature of this persona, she has a reputation of having lots of valuable information for uncommon procedures, leading to her receiving a lot of phone calls from colleagues.

Prototyping the prototypes

Once we had something to go on about the users we were going to design for we started drafting prototypes. We decided to create two prototypes we could A/B test, partly because we had several ideas for the information architecture and visual design, but also to explore the consequences of how switching medium (from analogue to digital) could affect the usage of the cheat sheets. We quickly hit a roadbump.

On the one hand, we wanted to do paper prototypes to get off the ground quickly and start testing. On the other hand, digital prototypes would be really nice to have to be able to test the switch to a new medium as well.

We decided to go straight for digital prototypes since we really wanted to explore the effects and possibilities of the change of medium, but it came at the cost of a delay (due to development time) before our first user test.

The feedback we got was valuable, but looking in the rearview mirror, paper prototypes would probably have been the better way to go so we'd have more time for user tests.

Testing, testing

Even due to the time constraints of our thesis project and the availability of the police officers, we still managed to do bi-weekly cycles between new iterations and tests of the prototypes.

We had a gut feeling that our users would see our prototypes as an improvement to their current tools no matter what, which kind of also was the reason behind creating two prototypes with identical content but different information architecture and visual design. This way, we could avoid feedback like "This is great!" and learn what they really appreciate with each prototype.

We held several user testing sessions with the officers to try and understand what they appreciated in the two prototypes (more on the differences between them later), looking at things such as:

Our initial thought was to give the officers the prototypes to test by themselves (when possible) while working. But due to the fact that the material (provided to us to build into the prototype) could turn outdated during the project, it felt neither safe nor fair. What if they committed misconduct while relying on information provided by us?

So how do we test our prototypes?

Setting the scene

Since we were aware of the fact that it may be difficult or dangerous for officers to test our prototypes in real work situations, we looked at framing and scenarios as design methods to substitute the situations that may suddenly occur while in the field.

The purpose of using these interaction design methods is to give some sense of context for the users testing the prototypes, e.g giving them a story of where they are, what they are doing, what tools they have at their disposal at the time of testing. We tried to make these stories and scenarios feel as 'real' as possible by basing them on situations (learned during the interviews) we knew the officers went through frequently.

Some examples of the scenarios include e.g when the officers are in a car driving to a location, or at a crime scene (e.g a break-in) where they feel they have the time and opportunity to read the material before taking any necessary steps.

The methods worked well overall, but getting the users in the right "mood" was a bit difficult.

Designing the prototypes

The context we designed the prototypes to be used in were occasions where the officers had time to read the material in the cheat sheets. These occasions were typically when they were in a car on their way to or from the station, or at a scene where they felt they had the time and peace of mind to read the material.

Furthermore, based on the initial interviews we realized there were four main variables that could affect the officers while using the prototypes:

We kept this in our minds while mocking our UI's, the goal being to create a prototype that could fare well in all above mentioned situations.

Information architecture

The cheat sheet material we got access to already had a determined hierarchy, which we did not want to change since the officers already were familiar with it. We did however modify and create different ways of searching and browsing the material, to make it easier for the users to quickly find what they were looking for.

Visual design

We wanted the UI to be as distraction free as possible, since the officers would encounter enough distractions and stressful elements in their work environment as is. This resulted in a UI stripped down to the bare minimum, focusing on the text content.

Contextual sorting

One concept we explored was to sort the content in chapters based on e.g the time of day or day of week. We learned that e.g break-ins were more common midday during weekdays, so the app would create shortcuts to those chapters during those days. This feature was appreciated by the officers but didn't make it into the final prototype due to time constraints.

Lessons learned

Time management

The biggest challenge during the entire project was the limited amount of time. For the thesis project as a whole (building prototypes, user testing, documenting, writing the thesis etc) but also managing the time our users had (due to them working full-time) to spend with us. This meant we had to plan and spend all the time we got with our users very carefully to make sure each interview and user testing session counted.

Personas as a design method

In previous projects during our education we didn't appreciate personas as a design method because we felt they often turned out too bland or just made up. this project however (since we had promised our users anonymity), they felt very natural to use and useful for communicating our findings, both internally within the police (to the higher ranked stakeholders), but also to our thesis mentors.

Interviews vs observations

Our initial gut feeling was that user observations would play an important role in this project, but since the current cheat sheets were used to such limited extent, we discovered that semi-structured interviews gave us a whole lot more to build our foundation of scenarios, prototypes and personas upon.


The exploration of switching the medium from paper to digital cheat sheets was interesting to test and observe, but we should have gone for lo-fi prototypes rather than going digital first. This would have probably given us time for more user tests and further iteration of e.g the visual design and contextual sorting concept.