How I developed the information architecture for the changes users need to report
This is a deep dive into how I came up with the groups, labels and structures for the things the user needs to tell us about and how we show them on screen.
These are the floor areas, air conditioning, outdoor seating and the like that affect the rateable value of the property.
There are too many of them to just lump them all together. We needed to organise these characteristics in some way.
Coming up with grouping options
I delved into the results from a small round of user research that asked users to group and name characteristics.
I also looked at some commercial property listings to see the kind of terms they used.
I came up with a couple of options and walked the team through them. We chose to go with the 3 group option, made up of:
rooms
internal features
external features
The 'rooms' group label was a bit tricky.
Even though this was a frequently used term in the commercial listings and was a top group name in the UR, we thought it sounded too residential.
'Area' came top in terms of frequency in the listings. But, I thought this would clash with asking for the size of the floor area e.g. 'You need to tell us the the area of the floor area'. I suggested the label 'use of space'.
Future proofing
For MVP day 1 we were only designing for all types of shops, as this accounted for the majority of business properties. I checked with product about how well these 3 groups would work for other property types. They said it would work well. An issue could be the industrials class (factories, warehouses, workshops) where we may need to create a fourth group and label for plant and machinery.
Translating groupings into design concepts
I came up with concepts for how we could display all these characteristics to the user. My aim was to avoid overwhelming the user with too much information.
Actions the user could do
I had a think about what the user can do to things in their property and how we can label them. A sticking point is that 'change' could be used as an overarching term that encompasses:
doing stuff to existing things
adding things that had not previously been present
removing things
It also can be used at a level below, to just cover doing stuff to existing things.
I went with the meaning of ‘change’ at the higher level, to reduce clutter by not saying both change and add.
From concepts to design mock ups
I mocked up screens in Mural to show the team how these concepts could look. We had a good session critiquing them. Our preferred design split out the 3 groups into different screens, with a 'task list' screen enabling the user to navigate between them.
End to end journey in Mural
I built out the entire journey in Mural. This was a great way to work. I could write content and get feedback from interaction designer Fran and other content designers, making edits on the spot. Then Fran created the Heroku prototype, copying and pasting content from each screen. He did an amazing job creating a dynamic prototype. You could pretty much select and edit any characteristic. This meant we had lots of flexibility in scenarios we used in user research, and user interaction during research sessions was close to real life.
Here’s a screen showing the task list with characteristics groups.
User research, insight and iteration
We put this journey through a couple of rounds of research and made iterations. The 3 groups and their labels tested fairly well. Some rating agents thought that ‘external’ could mean outside the property, and therefore not part of the valuation. But, no layperson ratepayers thought this. Some users found the term ‘use of space’ a bit unclear - but a design change was not on the priority list.
Responding to a requirements pivot
For one reason and another we had to change aspects of how this journey worked. To do this I:
removed the task list and made the overall journey linear
cut out playback of the information we held about characteristics
simplified how we ask users about a change to use of space
More testing
We put the revised design into testing. A phrase on the screen which asked the users how they’d changed use of space did not test well. On another screen it also emerged that users did not think that change described all the actions they could do.
More iteration
With a bit of hindsight I can see that ‘rearranged use of space in the property’ is a bit of a word salad. Because we were no longer asking for areas in square metres, I could use a phrase like ‘floor areas’ with no clash. And I could find a simpler way of saying ‘rearranged’.
In terms of change and add, it’s better to be clear than concise and unclear. Best of all is clear and concise!
I rolled out content changes across the journey that took these UR findings into account.
So, I started off with use of space, internal features and external features. And the term change meaning an overarching label for everything the user could do.
Responding to what users told us - especially layperson ratepayers, I iterated this to floor areas, internal features and external features. And I used the terms change and add.