Designing the CLUE Survey App

Geoplex
Geoplex
Nov 6 · 8 min read

The Census of Land Use and Employment (CLUE) provides comprehensive information about land use, employment and economic activity across the City of Melbourne. For the better part of 30 years, the City of Melbourne has collected this data for every commercial building in the inner city. During this period of time the City of Melbourne has surveyed some tens of thousands of businesses on paper-based forms.

Geoplex were engaged to develop a web-based platform for maintaining, collecting, visualising and reporting the CLUE data. City of Melbourne and Geoplex worked together in a collaborative agile environment to deliver the successful product, which replaces replaces a legacy MS Access desktop application and paper-based field collection process. The application developed saves tens of thousands of pieces of paper annually, improves workplace health and safety, and introduces significant efficiencies in data collection and data management of the Census.

In this first blog covering the CLUE platform redevelopment, we focus on the design process and principles we followed.


Design Approach

Geoplex was tasked with redeveloping the CLUE platform end-to-end. This included replacing the paper-based forms with a modern data collection application.

This meant that the field survey team would have to transition to a new unfamiliar interface on a tablet device, while also accepting that some of the things they were accustomed to would not be possible any more. For example:

  • Crossing out fields
  • Scribbling on top of existing text
  • Physically attaching business cards on a form.

Realising the importance of this, Geoplex followed a Design Thinking approach in order to understand the real needs of the survey team, and come up with a design that would provide an excellent user experience.

Initially, we organised user interviews where we tried to understand the process users had been following up till then and empathise with their experience; what they liked about using paper forms and what their frustrations where.

Analysing our notes later as a team helped us identify valuable insights that we eventually distilled into a list of key objectives to guide our design:

  • Every part of the form should be easily accessible, as users frequently go back and forth and rarely complete the form in order.
  • They key information on each form should all be available at a glance.
  • Switching between the three different types of forms that represent the CLUE data hierarchy should be easy and quick.
  • It should be easy to take notes at any time.
  • It should be easy to reference a map at any time.

Form Design

As we discovered in our interviews, the users’ workflow when filling out a form was often quite convoluted, and they rarely filled every item on the form in order. As such, we wanted our design to accommodate this style of workflow, so we quickly moved away from a vertical scrolling form design.

We broke up the form into tabs that users could navigate to either by swiping horizontally, or by clicking on the desired tab. This ensured that every item on the form was always accessible quickly without ever needing to scroll back and forth.

tabs allow the user to quick navigate through the forms.
Demonstration of swipe and click through tab navigation

By positioning all the key information fields on the first screen, the user immediately has all the critical information about the property available.

It is common practice (see Baymard and Nielsen Norman Group) when designing mobile forms to lay out each field in a single line to simplify the view and avoid breaking the vertical workflow.

We chose to go against this, as we believed that the advantages of saving space and having more information at a glance outweighed the disadvantages. Particularly considering that our design was not aiming to encourage a vertical workflow, and the users of the application are ‘repeat’ users. If our users were members of the general public who would use the site rarely, a vertical layout might have been more appropriate.

We ended up grouping two, three and even four inputs in the same line, but we always made sure that the grouped items were logically related.


Editable Table Views

Each property has associated data that can be too complex to be represented as a single input field, for example a building property has a list of floors against all of which data needs to be captured. Following the same principles as when designing the form layout, we created a control that would be compact and informative but at the same time easily editable.

Edit view for table rows

The above table control (shown here for building floors) was designed to achieve both goals. In the first view, the table is read-only. This allows us to condense the table data quite a bit and display all the critical information at once. When the edit button for a floor is tapped, a modal dialog comes up which allows for each attribute of the floor to be edited in a separate form. A similar dialog is used when the Add button is tapped. This second view can be more spacious as it only needs to show data for a single floor.


Navigation

CLUE properties under a specific address are organised into a 3-tier hierarchy and different data needs to be captured at each tier. We needed to provide the users with a way to access the 3 different types of forms they are required to complete for an address and we came up with the following ideas:

  • A tree-style navigation where users can expand and collapse the property tree to reach the desired property/form.
  • A button-style navigation where users can traverse the hierarchy using the top navigation buttons.
Mockup of tree-style navigation
Mockup of button-style navigation

Both approaches had strengths and weaknesses, but we regarded the button-style approach as superior because it would ensure more space for each property item and it could make navigation easier in certain scenarios. We weren’t sure how the users would react to each approach though, so we decided to prototype both and trial them with the team.

Contrary to what we expected, the feedback revealed a strong preference for the tree-style navigation because the property hierarchy was communicated more explicitly to the user. Having a clear indication of what felt right for the users, we could move forward with confidence.


Sidebar

Early on in our discussions with the users, they made it clear to us that they very often come across special cases where they have to take field notes or add extra information to a form. Users mentioned that in some situations they actually had to draw a rough map of the property as a note to the coordinators doing the post-processing or to other users who would revisit the same property at a later point. In addition to note-taking, being able to reference a map was also something they needed to do very often.

To address these needs, we added a sidebar that was always visible in all of the forms. It contained:

  • A map button that would bring up a map view with all properties in the current block
  • A notes button that would let the user scribble notes (including freehand draw)

Validations & Warning

A significant advantage of a digital data collection application is the ability to dynamically validate data and provide warnings.

Data quality and integrity are two key elements of the CLUE platform and we designed a validation and warning framework that enables surveyors to quickly identify required inputs, data validation issues and warnings in the field prior to submitting the survey.

A required input field is indicated by a blue dot.
When a user’s input is valid the app will highlight the field green.
Customised warnings present prompts to the user if applicable

Prior to submitting the survey a final validation is run and will prompt the user to fix any errors in the information collected. You will note that both the ‘property’ and ‘occupant’ tabs are indicating validation errors with a red bullet. This enables surveyor to quickly navigate through and find validation errors.

Validation errors are clearly presented with errors on other tabs clearly identifiable.

Design iterations

Much like agile software development, the design process needs to be iterative and our designs needed to evolve with each development cycle as we got closer and closer to understanding our users.

Observing how users reacted to our initial designs and discussing with them about their experience gave us valuable information on what we could improve. In subsequent iterations we made some small enhancements:

  • we changed the input types for some form items (e.g. swap a dropdown control for radio buttons).
  • we adjusted the table controls to prioritise fields that the users considered more important.
  • we made minor changes to the navigation and the labels we display.

Outcomes

The CLUE platform recently went live and the survey team have already started testing the survey app in the field. Our final design has generated a lot of positive feedback and the CLUE team is transitioning to fully replacing the paper forms process.

In our next CLUE blog we will discuss the architecture of this truly serverless platform.

Geoplexing

Experiments, new technologies, team culture and things we’re doing.

Thanks to Brendan Jurd and Harry Gaitanis

Geoplex

Written by

Geoplex

Mapping and Geographic Information Systems (GIS) specialists. We help you visualise data, drive competitive advantage and solve business problems.

Geoplexing

Experiments, new technologies, team culture and things we’re doing.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade