1. Crossing disciplines
(for fun & profit)
Working with UX, design & development

2. Me.
Elizabeth McGuane
@emcguane
Lead content strategist at LBi London
Mappedblog.com

3. What I’m talking about
Working
with teams
Working
better
Classic
movies
Documentation
Topic
maps
The
semantic Structured
Horses
content
web
Content
management

4. Working in a team

5. 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

6. The project: a website redesign
• Financial services
• Cross-brand
• 6000+ content items audited

7. And also
• Brand identity changing
• New CMS coming in
• Split between ‘digital’ and ‘brochureware’

8. What?

9. 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

10. 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

11. 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

12. Our story

13. 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

14. Our task
• Create a system that designed against duplication
• And create a central repository for help &
support content on the site

15. Our answer
• Modular content

16. 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?

17. 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

18. 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

19. Our big idea

20. Trying to find a movie to watch

21. Disambiguation: to remove uncertainty

22. So there’s this:

23. Oh but then:

24. Um.

25. We all need to be
talking about the same thing
and be sure we’re
talking about the same thing

27. George George George
Baker
Baker
Baker
(Horse)
(Jockey)
(Owner)
When ambiguity is present, we need to organise
information in a systematic, logical manner.

28. 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 )

29. What’s a topic map?
• A way of storing and relating those ideas

30. So simple, right?
• Sometimes simple ideas take a really long time
to understand
• Why does this matter?

31. 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

32. 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

33. So here’s what we set out to do

34. 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

35. What’s the site made of?

36. Who’s working on it?

37. What are our requirements?

38. What’s in a module?

39. When are we doing the work?

40. Reality is imperfect

41. Topic maps are kind of obscure

42. 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

43. People + budgets
= changing plans

44. 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

45. What I've learned

46. 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

47. 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

48. 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

49. Thank you!
@emcguane