2. A brief overview.
The what?
This project investigates how a mobile-based route planning application can be developed in order to decrease the workload of the
Danish food inspection agency and potentially relocate resources.
The why ?
The Ministry of Food, Agriculture and Fishers has already launched a digitization strategy with the purpose of streamlining the public
sector by utilizing technological advances.
The reason?
We believe that the increasing use of smartphones and tablets in both worklife and the daily life of people is an opportunity of great
value. Thus our case and project has concluded in a prototype of a smartphone compatible routeplanning design.
3. IT systems - Fødevarestyrelsen
The health inspectors of the Danish food inspection agency work in 5 synchronized systems.
- DIKO - The system of which reports are created.
- KOR: Contains information regarding enterprises fx. name, adress, postal code eg.
- PLS: A routeplanning tool.
- WORKZONE: Journalization
The systems listed above serves their very special purpose but are however vital in the daily life of the Health Inspectors.
PLS and Workzone use the various data, generated by the healthinspectors during the day. Thus these systems must be synchronized
with DIKO.
4. A brief introduction to PLS
Overview:
- Commercial software, currently PC based.
- Five years old.
- The system was developed in order to save time for the Healths inspectors and decrease the risk of enterprises
not being inspected in time.
- System is updated every three months by the system owners via user inputs.
- The user can generate a route automatically, The route will appear in a Krak map and can then be printed.
What’s the problem?
5. Our angle in relation to PLS
The catalysts:
- Health Inspectors are equipped with smartphones
their worklife.
- Some Health Inspectors are using the application
“Findsmiley” whilst performing inspections
- Some Health Inspectors find PLS too complex,
to overcome this complexity they devised their own various
ways of using the system.
The statments above lead to the following problemstatement: How can we design a mobile-application,
solving the challenges that the Health Inspectors are experiencing with the routeplanning in PLS?
6. Research methods
To gain insight of how the Health Inspectors viewed the system, we conducted semi-structured interview sessions
along with observationstudies with two PLS users.
User 1: Test pilot for PLS, is also the ‘go to’ person in relation to system inputs and issues. We labeled this user ‘the
superuser’ based on the user’s level of IT expertise.
User 2: An experienced Health Inspector with knowledge of the old route planning system however this user do not
have the same level of IT expertise as user 1.
Preliminary conclusions:
- The two users had very different goals and motivations for using the system.
- The two users had different views in relation to system-requirements.
- The two users used the system quite differently.
- The two users had different ideas about the inner workings of PLS
7. How to handle different user needs.
Approaches:
- User centered design (In order to specify the use-context for PLS
along with requirement-specifications)
- Evolutionary prototyping (We found this most compatible with
reevaluating the prototypes via iterative sessions with the users)
- Iterative design (Based on the results changes and refinements
were made when reevaluating design after an iteration)
- Design heuristics (In case of incompatible needs and desires
we resorted to using standardized design heuristics in order to avoid
a potentially biased design)
8. The design - Step by step (1/8)
Our research has shown that PLS plans
via information provided by the Health
Inspectors (each inspector is appointed
to a certain area etc.)
The application synchronizes with an
exchange calender, available in this
application. Which is why the user needs
to log in.
In terms of security (stolen phone fx)
the log in function also prevents
outsiders from gaining information
about pending inspections.
9. The design - Step by step (2/8)
- If the user has already planned a route, a
dialogbox will appear, prompting the
user to input whether the user wishes to
be redirected to ‘route of the day’ or
create a new route (in which case the
user hits Annullér).
- The purpose of the dialogbox is to
remind the user of already planned
routes. In case the user generates a new
route in spite of an already existing one,
the new route will overwrite the old
route, the old route will be dated in the
calender
10. The design - Step by step (3/8)
By pressing the menu icon, a menu will
appear. If a route has not been planned for
today it will appear in a pale grey color (as
disabled)
Instillinger contains information about
privacy policy, the ability to turn the GPS
off, and set the app to offline-mode
Aditionally the user will, as a standard, be
logged out after five minutes of inactivity
(which can be userdefined as well)
The calender uses log in information to
retrive data from the user’s exchange mail.
The blue dots indicates planned routes, the
blue ring indicates the date of the day, the
solid colored ring indicates that the user
has pressed it.
11. The design - Step by step (4/8)
By clicking the arrow the user can
view detailed information about the
organization. The arrow changes
direction to indicate, that the field has
been expanded and can be pressed
again to revert.
Additionally, the grey color appears
whenever one of the functions below
have been pressed.
12. The design - Step by step (5/8)
The user decides whether the inspection
will be done in 4- or 8 hours. The route is
planned qua this information.
Computer-PLS provides more options,
(morning, noon, evening etc.)
We did not include these as the user
(when using the app) will most likely be
heading out the door.
The reduction decreases the number of
choices, thus reducing complexity and
supporting percieved functionality
13. The design - Step by step (6/8)
The user specifies the means of
transportation and proceeds to click the
arrow. (If any buttons are pressed they
turn grey as in the previous steps)
The user can edit the suggested route
(example: pressing the bin in order to
delete elements, in which case the
application prompts a final Yes/No from
the user.
Additionally the user can view KOR
information and by clicking the smiley
the user gains access to two years of
controlreports.
14. The design - Step by step (7/8)
The user can drag organizations
and change the order of which
they will appear during the
inspection route.
By pressing “Tilføj område” the
user can add an additional area.
Once a sufficient amount of
areas has been added, the user
will be redirected back to
“Rediger rute”
By pressing “Anvend Rute” the
user will be directed to the final
step.
15. The design - Step by step (8/8)
In this step the route is shown in numeric
order, the user can still drag the elements
to change the order or go back and edit
the list in case a mistake was made.
The user can either print the the route
(Conditioned by the smartphone being
connected to a printer) or have the route
shown via GPS (as shown on the right)
16. Final thoughts
Why is this a good idea?
If implemented succesfully Healh Inspectors can quickly plan and edit routes on the go thus potentially saving time,
paper(!) and hours
The design is a counter initiative towards users, using the PC-PLS in their own way in order to compensate for
complexity.
The application includes all means of transportation as some users prefer to use their bicycle when inspecting.
The application makes it easy to generate routes for long periods of time.
The application is not conditioned by pre-existing IT knowledge.
The application is compatible with the digitization strategy and a public sector undergoing major innovative changes.
