Key takeaways from World Information Architecture Day 2017

in Front-End Development, Design

World Information Architecture Day is a conference that has been taking place every year since 2012. It has grown from being hosted in 12 cities back then to an impressive 58 (by my count) across 5 continents! This year was the first time there was an event hosted in Manchester so I took the opportunity to attend and take in some of the talks. Here is some of my key takeaways from my two favourite talks of the day.

"Visual vocabulary to visual language: what comics can teach information architecture" - Stuart Curran @stuartcurran

Stuart is a software design consultant at Thoughtworks and his talk was all about the comparisons that can be made between IA and comic books. He spoke about how comic books are a form of visual language that utilise similar patterns that you find in spoken language. In the comic book world, this language is used to convey a story to the reader. In the web world, this language can be used to do the same but it can also be thought of in terms of helping users to complete tasks. If a user needs to consume a certain set of information or navigate a certain path in order to complete a task, this can be aided by how a website is communicated to the user. If a website’s structure is hard to follow or interpret, it becomes difficult to navigate or complete tasks in the same way a story becomes hard to follow when it is poorly structured or has unclear language.

We have to design our websites to make their language and structure easy to interpret for users and this can be achieved by considering how we structure information, from not only a visual perspective but also a structural one. A good question to ask is, ‘where does a certain piece of information belong within its context?’. This is more effective than making a decision on the location of information on a website based purely on a visual point of view.

Stuart explained a comic book structure pattern. You have four key points, think of each one as a section on a comic book strip. They are, the 'establisher', the 'initial', the 'peak', and the 'release'. The establisher creates the base, like setting the scene. The initial creates something within the setting, think of the character of a film getting in to trouble. The peak is at it says, it is the peak of the situation, in a film this would be the bit where car chases happen and things explode. Finally, the release is the return to equilibrium, the happy ever after in films, and the completion of a task on the web.

This idea can be applied on a more micro level too. In the example above, the user might enter a kind of nested flow. For example, once the user has engaged with a navigation, they might be presented with a new establisher within the navigation itself and complete an establisher-initial-peak-release flow before returning back to the point of the overall flow they were in. This can be repeated throughout the whole process until the user completes their task, at which point it can be recycled.

Using grids as a timing system - Frank Santoro -

Explanation of the establisher-initial-peak-release pattern -

"The Chapel and the box: The value of the IA process" - Juls Hollidge @julshollidge

Juls is a strategist and information architect at Kore, a company which she co-founded. The term information architect is one she treated with a lot of care and is a label she has given herself, cautiously aware of the magnitude of the title and the work it results in. This talk touched on two main things, what information architecture really is and how it can be used to create better products / experiences / things.

Juls explained how, in her role of information architect, she goes into organisations with the aim of finding out as much as she can about every aspect of how that organisation works, the processes they have and the problems they are trying to solve. The extent to which she probes and explores has resulted in her often having to explain up front to her clients that her questions aren't loaded, or an attempt to uncover weakness in individuals, but instead a way to uncover every piece of information available.

The reason behind this is to build up a picture of what it is you are working with before coming up with solutions. The "what before the how". By exploring every tiny detail you are able to build a complete picture to guide you towards the best solution to a problem, or problems.

After the questioning phase, you can move on to identification. Juls likened this process to how her child breaks down and identifies every piece of Lego he has to work with before building something with it. This is the stage where you determine what your information is and what it means. Once you're at this stage you can begin to look for patterns and connections within the information and try to look for gaps in the knowledge. With this you can then start to craft solutions not only to the initial problem, but to ones you have identified during the discovery process. You can also make sure your solutions fit around, or successfully change, certain patterns and behaviours that you have found in the identification stage.

This can be summarised in 3 stages;

  • Identify - what is it?
  • Understand - what does it mean?
  • Structure - how does it fit?

Often people will jump to the last stage, ‘Structure’, and try to create something with whatever knowledge they have available. This the phase that is most visible to a client as it has the most tangible output. There doesn't tend to be an equal amount of time or effort spent working out what the information really means. The first two phases are harder to demonstrate the value of, they are less tangible, and as a result it is all too easy to skip the opportunity to fully explore knowledge gaps and truly understand complex systems, instead opting for a ‘try it and see’ approach. Despite this, there are times when people are able to create some good solutions to problems, but neglecting the first two stages (‘Identify’ and ‘Understand’) means you are more likely to have gaps in knowledge and a lack of understanding of both the problem and the factors influencing it, which could result in a sub-par overall solution.

The title of this asks, ‘When did we stop building chapels and start building boxes?’. An analogy for when did we stop building rich and detailed experiences in favour of those that are merely simple and functional (a theme that was touched upon by other speakers). I think there are trade-offs for both sides of this. Undergoing a time expensive process of collecting and analysing all of the information you can get could be unnecessary in some cases. The ability to quickly develop a solution that meets a business goal, which can then be improved through various iterations, taking into consideration more and more information each time, is an attractive concept and one that can be very effective. On the flip side, creating a solution without a good understanding of what it is you are creating a solution for can mean you are throwing darts at a dartboard blindfolded. Undergoing the first two stages gives you a detailed understanding and blueprint for any future solution. The sweet spot will most often lie somewhere between the two, and the degree to which it is weighted towards one method or another will depend on the specific circumstances. However, I think it is important to remember that these first two stages exist and can be incredibly valuable to the customer. It is about deciding when, where and how much to apply this process and to what extent.

Follow World IA Day at @wiadmanchester for updates on next years event!