
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
From a paper-based process to a modern data collection platform


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
An extremely challenging exercise that required designing a modern web based UX and UI to replace a data collection process with some 80+ data capture points.
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.


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.


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.


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.



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.

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.
