Crossing Disciplines: Content strategy, topic maps & multidisciplinary teams

Working with UX, design & development

Crossing disciplines (for fun & profit)

Me.

Elizabeth McGuane @emcguane

Lead content strategist at LBi London Mappedblog.com

What I’m talking about Working

with teams

Topic maps

Working better

The semantic

web

Documentation

Structured content

Classic movies

Content management

Horses

Working in a team

So what does it mean to be ‘multidisciplinary’?

•  I've never worked on a team that wasn't

•  Everyone brings their strength to the table

•  Free exchange of ideas and information are good

The project: a website redesign

•  Financial services

•  Cross-brand

•  6000+ content items audited

And also

•  Brand identity changing

•  New CMS coming in

•  Split between ‘digital’ and ‘brochureware’

What?

My team: Three (3) user experience experts

•  Knowledge keepers, owners of the investigative work

•  Developed and owned the personas

•  Developed the experience concept

Their aim: a content-led website

My team: Three (3) designers (in rotation)

•  Came in late

•  Moved around a lot

•  Working to changing design brief (cos the brand was changing)

Their design concept: Open, fresh and flexible

My team: One (1) developer (as a consultant)

•  Came in late

•  Reluctant CMS authority

•  Reluctant liaison with client developers

•  Never really worked on a collaborative design before

Their development concerns: Accessible, accessible, accessible

Our story

That audit: what we found

•  Content was being duplicated across the site

•  There was no central way to manage it

•  This, despite there being a ‘content management system’

Our task

•  Create a system that designed against duplication

•  And create a central repository for help & support content on the site

Our answer

•  Modular content

The issues this raised

•  Content is no longer a ‘page’

•  Some of it is unique, some goes across a section, some is universal across the site

•  So how do we manage it while we’re creating it?

•  And how do we govern how it should be used in the future?

Dealing with humans

•  Our team was fluid – people joined and left as other tasks came up

•  We needed to communicate with other disciplines, some of whom weren’t working with us

•  We wanted an easy way to explain our modular content system to them over time

So: content (me) and UX (another guy) had a big idea

•  As content was repeatable, we needed to map its instances

•  Our documentation had to encompass UX principles, design principles and content strategy

•  And we were launching the project in phases, so it had to be carefully documented in a usable way

Our big idea

Trying to find a movie to watch

Disambiguation: to remove uncertainty

So there’s this:

Oh but then:

Um.

We all need to be ���talking about the same thing���

and be sure we’re ���talking about the same thing

When ambiguity is present, we need to organise information in a systematic, logical manner.

George Baker

George Baker

George Baker

(Horse) (Jockey) (Owner)

What’s a topic?

•  A set of ideas that you want to say things about

–  (So, a ‘topic’ is about as meaningful as a ‘piece of content’)

What’s a topic map?

•  A way of storing and relating those ideas

So simple, right?

•  Sometimes simple ideas take a really long time to understand

•  Why does this matter?

Normal links don’t do this

•  Writing a ‘page’ in HTML, you can decide to link any two pieces of content together, regardless of topic

•  Topic maps demand clear topic-based relationships – they force you to codify what you’re talking about

Why this idea matters in a closed system (like a set of project documents)

•  Relationships between different ideas can be instantly accessed and understood

•  Concepts like authors, sentences and document ownership are irrelevant

•  The map can evolve over time without requiring rewriting or versioning

So here’s what we set out to do

We set up a topic map for our developing designs & content requirements

•  Designed to give all disciplines an equal grasp of the site’s design, content and functional elements

•  Built in Topincs, a web-based topic maps platform

What’s the site made of?

Who’s working on it?

What are our requirements?

What’s in a module?

When are we doing the work?

Reality is imperfect

Topic maps are kind of obscure

And the technology itself still needs to mature

•  It’s difficult to explain and understand because current literature and systems were created by experts for experts

•  Sometimes we embrace complexity – we fear things that are too fluid and simple

People + budgets = changing plans

This whole process was a learning curve

•  We knew what we wanted to achieve, but had minimal technical support

•  We were dealing with a morphing project & changing timelines

•  So… we had to fall back on some traditional documentation to keep up

What I've learned

1. Documentation is about communication

•  And it should exist for a reason – to allow different groups to communicate without confusion

•  Cross-discipline documents are like the semantic web – they need to codify information so that it makes sense in any context

•  No document in the history of forever has achieved this

2. Content needs to be free – and so do we

•  Our content was modular, and that meant we needed to record its repetition and variants

•  A spreadsheet is not the best solution for this (or for a lot of things)

•  We could use a system like this to free ourselves from Word-based content production

3. We can work more elegantly

•  By collaborating in earnest, at the start of the project when it matters most

•  By using the tools available to us to distribute information, not create documentation-as-deliverable

•  By embracing other disciplines’ skills and focus, and sharing our own

Thank you!������

@emcguane���