Crossing Disciplines: Content strategy, topic maps & multidisciplinary teams
-
Upload
mapped-a-content-strategy-blog -
Category
Education
-
view
1.629 -
download
0
description
Transcript of 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���