You’ve worked hard on the information architecture models you’ve created but haven’t been able to sell them to the client, or your co-workers. Maybe the conversation around the IA has broken down into an unhealthy debate over semantics. In another scenario, you are tasked with creating a controlled vocabulary for a large organization that has a silo mentality and a lot of legacy content. Where to begin? These scenarios will sound familiar to most IA professionals. In this workshop, Abby will share her techniques for getting an organization that may have different ideas about how to organize and name content to agree upon a controlled vocabulary. Abby will share specific tools in the form of diagrams, beyond the ubiquitous sitemap and wireframe, which communicate complex ideas. And she’ll share techniques for practicing information architecture with clients collaboratively. I want to focus on the soft skills that make someone good at IA. So the lessons here are really about leveling up in skill set. Including: - Conflict Resolution in IA - Selling IA to others in your organization - Improving stakeholder interviews - Facilitating Low Fidelity Conversation about language - Visualizing language with simple pictures to get clarity

1. Collaborative
Information
Architecture
abby Covert | @abby_the_Ia

2. What do you hope
to get out of this
workshop?

3. objectives
• Understand the advantages to practicing
information architecture collaboratively
• Discover collaborative facilitation techniques
to use with coworkers and clients
• Build your toolbox with new diagrams and
techniques
• Answer common questions about practicing IA
collaboratively

4. why is it
important to
practice Ia
collaboratively?
Section 1:

5. what Problems does talking
about Ia help to alleviate?
• Disputes over what to call things
• Lack of clarity on what things “are”
• Overlaps in functionality & duplication of effort
• Lack of prioritization of audiences or goals
• Technical debt created by inconsistency or lack of
reusability of patterns
• Organizational inefficiency due to communication heft

6. Who practices Information
architecture?
• Specialists AND generalists
• Innies AND outies
• Designers, technologists AND business folks

7. What conflicts are common?
• Speaking different languages based on role
• Arguing about priority through a lens of organizational politics
• “This is how we have always done it” thinking
• Lacksonomy instead of taxonomy
• Other competencies ignoring or over-riding decisions made by IA
• Other competencies seeing IA as cosmetic and arbitrary
decisions
• Lack of time or budget for collaboration, testing and iteration

8. Story time
to: Jenn@bigCompany.com
from: Ann@bigCompany.com
Subject: We are hiring!
I am thrilled to announce we are planning to hire
3 new UX designers in the next month and another
5 by the end of this year!

9. a hypothetical conversation
between Jenn and ann

10. Jenn and Ben set out to get
the lexicon started
to: Ann@bigCompany.com
from: Ben@bigCompany.com
Subject: Lexicon
I really enjoyed working with Jenn last week on the
lexicon assignment. Is there any way I could get all
of my team members access to it when she is done?

11. What could Jen have done
differently to mess this up?
• Jen could have written the lexicon alone based on her
understanding of the concepts and not asked for Ben’s help
• Jen could have written a draft of the lexicon and presented it
to Ben for his feedback, making the meeting more of a critique
• Jen could have emailed Ben a list of words and asked him to
write definitions of them for her (spoiler alert: he may have
never answered the email, taken forever to answer or written
overly complex and/or confusing definitions she would then
have to ask tons of questions about)
• Jen could have spent the whole time talking to Ben trying to
understand his point of view instead of picking up a marker
• Jen could have gotten frustrated over their lack of common
understanding and given up on the exercise entirely

12. what does this story teach us?
• Lesson 1: People can assume they understand
something clearly, until they compare that
understanding with another person’s
• Lesson 2: Complex definitions are sometimes
easier to discuss visually than just verbally
• Lesson 3: Defining concepts can be seen as a
helpful activity when done collaboratively and cross
functionally. The same activity when done in a silo
can be frustrating and seen as a waste of time

13. How can I make time or get time
for information architecture?
• Don’t ask for time for “doing the IA” — instead bake
talking about language and structure into every
interaction you have throughout the process
• Document the conflicts that need to be talked
through and explain the people and process you
need to resolve the conflicts
• Explain the ramifications of not resolving these
conflicts and building on “shaky ground”
• Be ok with the decision or mandate to build on shaky
ground (I use the three times at bat rule for pushing
back)

14. How does Ia fit into different
process styles?
• Agile: In Agile language and structure is defined very quickly
meaning that IA needs to be an ongoing discussion. Advice here
is to make sure there are KPIs being measured around structural
and linguistic integrity. Also make sure the IA documents are
shared and editable by anyone in the organization.
• Waterfall: In waterfall, you are more likely to be asked to create a
stopping point after which IA is “complete.” Advice here is to try to
position IA as something that isn't ever set completely, so that it is
shared amongst all stages of the process. This means that things
like maps and controlled vocabularies are continually updated
throughout the project.

15. How do I communicate Ia to my
organization?
• “Information architecture is a practice of deciding how to arrange
the parts of something to make sense as a whole. Because
what we call things and how we arrange them makes a big
difference to whether our users will understand us”
• “IA always exists, whether of not we think about it. If we don’t
think about it we are letting it grow organically which isn't always
the clearest and most effective way forward”
• “By thinking about IA our team can make sure that the language
and structures we choose will help us to reach our intention”
• “IA is best practiced collaboratively, so while I can help to
facilitate us thinking about our IA, I can’t do this without help of
others in the organization”

16. Dos and Donts of Communicating
Ia in an organization
• Don’t talk about IA
as a step in the
process
• Don’t propose IA as
a gate you have to
get through
• Don’t talk about the
concepts, talk about
the results
• Don’t try to own the
IA as an individual
• Do find places within the process
to talk about the clarity of
language and structure
• Do talk about IA as something
that will continue to grow and
change over time
• Do ask questions throughout the
project that makes it clear that
talking about IA is important
• Do assemble a group of people
that share the responsibility of
making IA decisions over time

17. Create a
Communication
Plan for Ia in
your organization
Exercise 1

18. My Ia Communication Plan
What issues do you see in your organization that IA could help alleviate?
Who are the people
who would be easiest
to communicate IA to?
Who are the people
who would be hardest
to communicate IA to?
Who are the people who
would be most critical to
communicate IA to?
What obstacles do you face in communicating IA?
What would need to happen to lessen those obstacles?

19. Facilitation
techniques for Ia
collaboration
Section 2:

20. Stakeholder interviews
• Step 1: Identify the right stakeholders
• Step 2: Design the conversation
• Step 3: Seek Patterns & Divergence of Opinions
• Step 4: Be a mirror

21. Identify the right stakeholders
• Use the organization
chart to visualize who you
plan to talk to
• Make sure you are talking
to enough representative
people across the org
both in terms of level and
area of focus

22. Isolate them from the herd
“We think _________” “I think __________”

23. Design the conversation
• Position: Establish where this person sits in the space you are
exploring
• Convictions: Understand what they believe to be true and why
• Doubts: Understand what they have a hard time believing, what
makes them nervous and why
• Color: Ask anything else that will help to color in their
responses to their previous questions
• Questions: Always let them ask you questions. Sometimes the
best stuff comes out from what they ask

24. Some of my go-to questions
• If you had a magic wand and could change any one thing about
_________ what would it be and why?
• What do you see as the strengths of ___________? What about
the weaknesses?
• Is there any language that you see getting in the way of
communicating with our customers?
• Is there any language that you see getting in the way of
communicating internally?
• Is there anything I haven't ask about that you think I should know?

25. Some pointers
• Listen more than you speak. This is not your time to prove
how smart you are or share ideas or perceptions you have
• Leave silence. If they need time to think about their answer
leave them the silence to do so, don't react by expanding on
your question or rewording
• Record your interviews so you can be more active in listening
and making eye contact. Take simple notes throughout to
show that you are getting something out of the conversation
• Keep your notes in a spreadsheet organized by question so
you can sense patterns more easily
• If you take notes right after each interview, you will be more
likely to stay engaged in the material and it feels less like a
slog to get through

26. My template for note taking
Question Interviewee Name Interviewee Name Interviewee Name Interviewee Name
Question 1 Response Response Response Response
Question 2 Response Response Response Response
Question 3 Response Response Response Response
Question 4 Response Response Response Response
* Arrange columns and color code groups of people within a similar place in
the organization or role

27. Seek Patterns & Divergence of
Opinions
• Look first for the things that people agree on. Write a compelling headline
for each.
• Look second for the things that people are not in agreement over. Write a
compelling headline for each.
• After making a list of all the headlines in a spreadsheet, assign keywords
to each to see how they may be related to one another
• Area of the product/experience
• Sentiment of the concern
• Heuristic principle that is illustrated
• Start sorting by the keywords to see what emerges
• Create logical groupings of findings connected by a theme
• Decide the right order to present findings in

28. Example from my work
Example of Findings Spreadsheet
Example of Findings Presentation

29. Be the mirror
• If you think a point is obvious, make it anyways
• Present the why, not just the what
• Share quotes from interviews without attribution to get points
across that are tough to make
• Don’t let your opinions leak into what you present
• Say the thing that everyone was talking around but not saying
• Ask questions of the group based on what you heard
• Present both sides of anything that might be disagreed on
• Visualize mental models that differ from one another

30. How to have low fidelity group
conversations about language
• Set an agenda with time blocks and share it with attendees so they
know where you are going with this activity
• Start by asking the group about opportunities and risks that this
session has. Have everyone write their answers and then go
around and share with the room.
• Arrange the agenda from broad to specific
• Breakdown mental models slowly:
• Start with giving people time to think individually
• Then pair people up to compare notes
• Then have pairs combine into small groups
• Finally open to full group discussion

31. an example agenda

32. What about for really big
groups?
• Facilitate smaller groups with similar mental models to get to know
their thought process better
• Identify one person who can represent that group in a larger, more
cross functional group. This person should be:
• Interested in the activity
• Allowed to take action
• Willing to listen and participate in semantic debate

33. pointers for Running a
collaborative ia session
• Ask people to set aside technology for the session (don’t allow the
“I’m taking notes” excuse… they aren’t, instead establish a note
taker for the group and project their screen as they take notes)
• Don’t be afraid to call on someone who hasn't spoken up
• Always establish a parking lot for topics that leak into the meeting
that aren't the focus. Allow anyone to call “parking lot”, and make
sure it gets written down so it is actually parked.
• Always position collaborative sessions as exploratory, meaning
there are no bad ideas or wrong ways of thinking
• Ask for honesty AND kindness as activities are undertaken
• Always end a session by asking for advice of your participants. “As
you know, I will be working on the things we talked about today,
what advice do you have for me?”

34. Visualize language with simple
pictures to get clarity
• Draw and Share: Have your attendees draw the
concept in the way that they understand it and
compare their drawings with each other
• Round 1: Individual Draw
• Round 2: Pair Draw
• Round 3: Groups of 4 Draw
• Round 4: Facilitated Draw
• Pictionary: Have one attendee draw their
understanding of a concept so that others can react to
it and ask questions

35. an example from my work

36. Dealing with difficult people
• Identify anyone who is potentially difficult during the stakeholder
interview process. Spend extra energy making sure that person
feels heard and understands the process they are taking part in
• If things get heated in the session, give that person the marker
and ask them to visualize the conflict as they see it
• Take their side for the sake of clarifying the conflict. “I think I see
what so-and-so is saying here…”
• If they are mean or inappropriate, tell them that is not productive
to the discussion and remind them that this collaboration involves
seeing many sides of the same argument
• Don’t be dismissive of their opinion or ideas but make them
explain themselves and answer to others’ questions about it

37. Have a low
fidelity
conversation
about language
Exercise 2

38. Instructions
• Round 1: Draw a visual model of this conference
• What are the pieces of it?
• What are the connections between those pieces?
• Round 2: Compare your picture with a partner
and create a combined model
• Did you use the same words?
• What pieces or connections did have that you didn’t?
• Round 3: Compare with another team and create
a combined visual model

39. How to Mine for language
Language in
the product
Language in
the marketing
Language in
help & support
Language we
use internally
Language users
use naturally
• Look for needless duplicity
• Look for legacy terms that
have stuck around
• Look for inside baseball terms
that might not be clear to users

40. Visualize similarity &
relationships

41. ask questions about efficiency,
clarity and intention
Do we need all
five labels for
this thing?
Are these really
the same model
with two labels
or two different
concepts?

42. Is this a difference of Model or
simply a difference of Label?
vs.

43. Sometimes different labels for
the same thing is appropriate!
(on mobile) (on desktop)
vs.

44. Tips for mining for language
• Start with nouns. Take on verbs secondarily. Beware of
adjectives.
• Use notes from user and stakeholder interviews to layer
on verbal only language that might be useful to
understand in connection with documented language
• Ask questions like:
• “When you say _____ what do you mean?”
• “Is _____ the same as ______?
• “Why did we start calling it _________?”

45. Controlled Vocabularies
Term Definition History Approved Synonyms
• A good controlled vocabulary:
• Captures the history of a term
• Lists the other words that may describe the same model
• Defines terms simply and defines words within the definition

46. Ideas to get people to actually
use the controlled vocabulary
• When first created: consider distribution through a “word of
the day” feature
• To get people to retire terms: Make posters of “words we
don't say” and post them in the meeting spaces around your
office — when all else fails, try using a gym whistle
• To make sure it stays fresh: Create a cross functional
working group to govern upkeep of language documentation.
These folks are like resident advisors for ontological choices.
They help resolve linguistic issues and educate others on the
documentation available
• To make sure it is adhered to: Make a linguistic review part
of the standards that are expected to be adhered to in terms of
style guides or launch checklists

47. Story time: why It is important to
define the words within the words

48. diagrams That
can be created
collaboratively

49. Association Diagram
• Illustrates connections
between concepts that don’t
adhere to navigable paths
• Best for showing hierarchical
relationships at a higher level

50. Association Diagram (example)

51. Block Diagram
• Illustrates how objects and
their attributes interrelate
• Best for breaking complex
concepts into smaller pieces
for discussion and
clarification

52. Block Diagram (example)

53. Journey Maps
• Illustrates how a process or activity happens across
contexts and channels
• Good for helping people break down silos and look at
things from the end users perspective

54. Journey Map (example)

55. Swim Lane Diagram
• Illustrates how many people
work together on a single
process
• Good for documenting the
tasks within a task and how
those map to role

56. Swim lane (example)

57. Gantt Chart
• Illustrates how tasks relate to
each other over time and role
• Good for breaking a process
down to reveal predecessors
and dependencies

58. Gantt Chart (example)

59. Aim to be
realistic, not
simplistic

60. Quadrant Diagram
• Illustrates how a group of
concepts or ideas compare to
one another on two or more
qualifiers
• Best for prioritizing or
showing white space

61. Quadrant Diagram (example)

62. Tips for Collaborating on
diagrams
• Share the work of writing and drawing with your partners
• Take the time and space needed to get through the
material, don’t rush or exhaust people
• For more complex subject matter, take it in rounds - not
all at once
• Keep it messy and low fidelity until the content is feeling
solid enough to get confirmation on
• Always have a format in mind when collecting but stay
flexible as you figure out what is needed

63. Tips for getting feedback on
diagrams
• Share the diagram ahead of a critique meeting for people
to spend time looking at
• Take the time to sit down with a few key stakeholders one
on one to show them the diagram with the intent to make
it clear. Don’t spend this time convincing them. You are
usability testing the diagram and they are your users
• Keep the visual polish off the diagram until the content
has been confirmed, this makes it quicker for you to edit
but also encourages feedback
• Always ask for critical feedback on how to make it more
clear and try to not defend or explain things you think are
already clear

64. Unnecessary
exactitude
Not Tidy
Designed
before
Architected
Unclear
Audience
Icon
Issues
Not appropriate
for scale
Unclear scope
Unclear
timescale
Unclear
context
Lengthy
labels
Not appropriate
for medium
Too Many
Colors
FREE No Labels Stacked Type
Confusing
relationships
between things
Unclear
intent
Unclear
Labels
Color doesn’t
mean what we
think it means
Hard to read
Misleading
Data
Manipulation
Unclear
Logic or Flow
Contrast
Ratio issues
Confusing line
crossings
Ill alignment
or spacing
Diagram Critique Bingo
http://abbytheia.com/2015/02/17/diagram-critique-bingo/

65. What is one thing you
learned today that you
will take back to work?

66. What I hope you learned today:
• Too much IA is practiced solo, and presented to others
• By sharing the responsibility we can get further, faster
• Practicing IA collaboratively means putting aside your
ego (and sometimes your ideas)
• There is no singular process or defining
documentation technique that always works,
prescribing is part of the work
• Anyone can practice IA, and more people should be

67. Q & a

68. How do you
establish trust
when you don't
have years of
experience?
Burning Question:

69. Are there any
pure Ia jobs
anymore?
Burning Question:

70. Can we practice
great, effective
ia with others
without them
knowing that it
really is?
Burning Question:

71. is it possible to
architect something
that you don't
understand yourself.
It's just too big, too
specialized or too
complex?
Burning Question:

72. I wrote a book
about information
architecture for
everybody!
http://
abbytheia.com/
makesense/