On Saturday Feb 12, 2012, I was fortunate enough to join a select few across North America and around the world in celebrating World IA Day here in Vancouver.
Big thanks again to Lynne Polischuik for her great organization efforts and including me in the event.
I presented a talk about OpenRoad's work on the City of Vancouver website redesign project. In its entirety, here's the link to the presentation:
Want to read more form Gordon Ross? View more of his presentations.
The City is not a Site Map*
*with apologies to Christopher Alexander
World IA Day 2012, Vancouver
February 12, 2012
Gordon Ross, VP/Partner, OpenRoad
Happy World IA Day!
As information architects and interaction designers, I think it's safe to say that many of you in the audience would agree that we get to work on some pretty challenging problems.
And from the IA types that I meet locally and at conferences I've attended, it also strikes me that many of us find deep satisfaction in the work—it often has a great personal resonance with us. A meaningful problem that connects with a part of who we are, not just something technically demanding.
Well, I can count working with the City of Vancouver a couple of summer's ago as one of those wonderful collisions of intense professional challenge and deep personal connection. I was born here in Vancouver, grew up in the burbs and have lived here my entire life. And I've had this nascent interest in cities for quite some time, and I've always been fond of Vancouver's short, but fascinating history.
So when we were selected to perform the information design work for COV's website redesign, it wasn't without a bit of trepidation that I approached the project. 60,000 page website, approximately 12 years old and growing by several hundred pages / month, 7 million visits / year from citizens and those abroad, several million dollars’ worth of e-service transactions—and the mandate from the City to fix it—it wasn't meeting expectations, it was difficult to find information—the information equivalent of some sort of urban sprawl gone bad.
One of the big design problems the City was facing is a classic IA design anti-pattern: a big chunk of the City's 60,000 page website was designed around their org chart.
Anyone else seen this? Hands up for those of you who have worked on a redesign project in the past couple of years that mirrors this design pattern?
Why is this a problem?
So why is this is a problem? What's so bad about designing a website around an organizational structure, especially a big organization like the City?
Because citizens don't get it. By organizing information in this matter, citizens need to understand the design of the City's bureaucracy in order to navigate to the right spot in order to engage with the City in the provision of a service or information.
And, most citizens don't appear to be terribly interested in making this investment in learning how their local government organizes itself. They have places to go, things to do, people to see, jobs to get done, families to raise, traffic to battle on a daily basis, garbage to put out in their alley, parking tickets to pay, and a plethora of other things that constitute their daily urban existence.
Learning about the City's org chart doesn't rank high as a priority.
So how do we categorize information in a way that people understand it?
Isn't that *the question* when it comes to all of our design projects?
Hold that thought. I want to take a quick detour here.
Chicken, Cow, Grass. Silently write down (or type) down which one of these does not belong?
Everyone who said cow, standup
Everyone who said grass, standup
Everyone who said chicken, standup
So we just replicated an experiment that Richard Nisbett describes in his book the Geography of Thought to demonstrate the different mental models of "western" and "eastern" cultures—primarily those influenced by a Greek philosophical tradition and those influenced by Asian philosophies.
This experiment has also been run in its popular and ridiculously cute overload Monkey, Panda, Banana variation with similar results.
But I wanted to spare you the danger of running it today.
And the crux of the categorization schema is that western types usually lump chicken and cow together because they are both animals, part of the same class of being, and eastern subjects tend to lump cows and grass together because cows eat grass—they have a relationship with each other, whereas chickens don't. Now I've done this with people who lived on farms and I've been told that chickens do in fact eat grass from time to time, but bear with me.
Richard Saul Wurman
Point of this lovely little thought experiment is something that every IA should know and use when working with their clients, large and small, and that is that categorization is an ambiguous schema. The man we have to thank for the term IA, Richard Saul Wurman, points that out with his LATCH acronym—the five ways we have to organize information, three of which are unambiguous: Location, Alphabet, and Time and the other two ambiguous ones, Categorization and Hierarchy (or continuum).
So backyard chicken/City of Vancouver jokes aside, this was the entry point for me to try to get City staff thinking differently about how to organize the site. I had the City management team perform that same thought experiment in a presentation. I convinced them that maybe the chicken was the odd one out and not the grass after all.
So you might be thinking, yeah, man, let's avoid ambiguous categorization and stick with something safer: let's focus on the user. focus on the user! Of course! the user! Now I've seen many well intentioned civic governments adopt a design pattern that starts with the user. And puts them into one of 3 major buckets:
To Delta and Nanaimo locally to such high profile cities as New York City and San Francisco, this IA design pattern has been replicated over and over and over again:
Resident, Business, Visitor.
Now I'm opposed to this schema. And here's why. Putting these three choices in front of the user when they hit the front of your website is like holding up a giant cognitive and existential stop sign.
And that stop sign is this question: who am I? Or rather, who does the city think I am?
And once you've figured that one out, then ask yourself, "What am I doing here again?"
And then you have to merge those two constructs back together and ask,
"based on who the city thinks I am, where would they put what I'm looking for to help me get done what I'm here to get done..."
And once you're through that door, it's, "Uh, department am I looking for?" Who am I again?
You can see why this is an issue.
Call centre person
The questions we should be asking, if we could speak with the citizen or business or visitor is "Hi, how can I help you today? What are you trying to accomplish? And perhaps even the question of "Why?" to help understand our visitor's motivations, provide some context in assisting them.
But most civic governments don't have the ability to ask their website visitors what they're looking for or what they're trying to accomplish every time they visit, so they conveniently use another internally focused categorization schema to organize content.
So to recap, I'm can now be clearly labelled in IA circles and bad mouthed on twitter as being anti-org-chart and anti-audience-segment. and that covers about 80% of the the civic websites I've ever seen.
Well, what am I suggesting?
Well, all hyperbole aside, I do believe starting with the user is the right place. We derived personas with City of Vancouver staff using some nifty narrative techniques. We grazed through about 4500 citizen survey responses, including a wealth of open-ended question data, we mined 311 call log data, and everyday we did some observational research to and fro City Hall and throughout our travels in the city.
And one thing that became apparent during our research was what I perceived as a figure/ground problem.
All you designers should be familiar with this famous image from gestalt psychology...
City of Vancouver
And that problem is that in every conversation and every interaction we were having, there were two competing images: the city of Vancouver and the City of Vancouver. And one was clearly the figure and the other was the ground. And more often than not, they were competing against each other.
I called this the small-c-city / large C City problem.
And my hunch was, that in order to better serve the Large C City in its ability to service the citizens of Vancouver and users of its website, we needed to better understand the small c city, the thing that most people think of first when we're talking about Vancouver.
And that led to this question.
What is a city?
Thankfully, someone had asked that question before. Google told me so.
His name is Lewis Mumford. And I even owned the book at home with the essay inside of it, a remarkable text called The City Reader.
In his own words then....
The city in its complete sense, then, is a geographic plexus, an economic organization, an institutional process, a theatre of social action, and an aesthetic symbol of collective unity. The city fosters art and is art; the city creates the theatre and it is the theatre. It is in the city, the city as theatre, that man’s more purposive activities are focused, and work out, through conflicting and cooperating personalities, events, groups, into more significant culminations.
- Lewis Mumford, What is a City? 1938
Wow. Now we're onto something. And it was written in 1938. Bravo Mr. Mumford.
In case you missed all of that, here's the bullet point version:
- Geographic plexus
- Economic organization
- Institutional process
- Theatre of social action
- Aesthetic symbol of collective unity
So really, the small c city isn't so small after all—it is *the city*, the aesthetic symbol of our collective unity.
Small C / Big C
Small c city of Vancouver= that which is in focus for most of the citizens, most of the time
Big C City of Vancouver = that which they come into contact with, but might not even realize it
Municipal government, has a remarkable impact on our daily lives, but for many citizens, it's simply invisible. I'll get back to that important thought in a bit.
And this figure/ground thing finally congealed into some kind of conceptual IA design manifesto for myself and my partner in crime on the project, our Senior UX Designer at OpenRoad Selma Zafar, part way through that summer. Here's what we wrote:
Our city IA Manifesto
How I, the citizen, understand Vancouver as a physical location and collection of social facts is going to permeate and dominate my understanding of the institution that shares in the governance of its existence; therefore, we, as designers and maintainers of the website, need to align the experience of dealing with the institutional City as closely as possible to the experience of the geographic, social, and economic city in hopes that we can connect to the citizen’s mental models and achieve an intuitive website experience.
Now for many of you here in the room, the simple assumption that a website will be based on the mental model of the end user and not some top-down taxonomy that you come up with in your cubicle cranking away in Visio or Omnigraffle, is a pretty obvious truth to how you work. And that's great. But for a lot of people in the world, many of the clients of our professional services work, have not yet made that leap.
This is still a revolutionary thought. And it is revolutionary because it has broad implications to how information is designed and content is created. And who is required to produce that content at the organization that may or may not be used to collaborating along audience lines.
So we started to work on a categorization schema that pulled in as much as we knew about the real world of living, working, and playing in Vancouver that we could during our project. We went broad as well as deep. We found great inspiration in simply looking at other examples of how Vancouver (and other cities as well) were represented using the fundamentals of LATCH—location, alphabet, time, categorization, and hierarchy.
We found rich, deep, and insightful representations wherever we looked, from historic representations of the city to modern cultural ones to the quite remarkable present ones. And we thought about things like time; both kitschy and serious.
And I think the challenge for IA's, once you let yourself start to explore a topic like an IA for a City and start asking yourself questions of "What is a city?" and "how do city's work?" and "do city's themselves have information architectures?"—I think the hard part once you've started down that path is coming to some kind of decision. Because design is decision making. And at some point, real artists ship, right? Our project had a timeline and a budget and at some point, we just had to produce something...
So for the remaining few minutes I've got up here, I want to share with you not the final IA that we came up with, I'll leave that for the day the City re-launches their vancouver.ca site, which I hear from the team is happening soon.
Instead, I'd like to share with you a specific artifact that we left with them, which I hope might be of use and inspiration to some of you in your future IA work as well.
We called it the "design implications" deck for short hand, and that expression comes from, if you trace it far enough back,
the first edition of the Polar Bear book that really made an impression and so wonderfully defined a genre for me. My parents still didn't understand what I did all day long, but I knew that it had a name. And that was exciting.
In that book, Lou and Peter unpacked the black box of information design in a little table somewhere in Chapter 11 that could easily go unnoticed by the reader. That little table has 3 headings: observation, conclusions, IA implications. And that, for me anyhow, is the basis of all design work that we do. We observe stuff out in the "real world"—we then make conclusions about those observations, an answer to the question, "Well so what if you saw that out in the big wild world." and from there we ask ourselves another "So What question"—well so what does that mean for the design of the site. And as we walk up some of the rungs of the ladder of inference as it's known (which can be fraught with some slippery steps and rickety ladders along the way), we make sense of our work and help people understand what we saw, why it matters, and what we're going to do about it.
Observations, Conclusions, and Design Implications. Simple & Powerful.
For the City, I added what I deemed most significant thematically into our design implications deck—knowing full-well that our time on the project would end and we might be handing our work over to another team to build the site, which did in fact happen. This deck I hoped would become a bridge, an important design artifact, and remind future designers of some of the rationale behind why we designed something a certain way. It forced us to be reflective, explicit practitioners, something as professionals in a discipline that is again in its pretty early days compared to other professions out there, felt like the right thing to do.
It hopefully connected the observations of the authors (accumulated through design research, in-person interviews, staff workshops, citizen surveys, and more) to the practical hands-on task of designing the new website.
It is intended to ground the designer in the ideas that shape the city of Vancouver, transforming abstract civic concepts into tangible website design interventions. Along with the deck of standard IA deliverables (wireframes, personas, presentations, and IA spreadsheets) this was an important souvenir for the project.
The deck starts with few provocations, one of which I shared with you from Lewis Mumford from his essay What is a City. I included quotes from Alex Marshall's book "How Cities Work"—I quoted at length an extract from an interview with urban design guy and recovering IA Adam Greenfield and I included this wonderful map and piece of inspired IA in the back of the book "Cities from A to Z".
The lines are "history, settlement, technology, commerce, pleasure, nature, traffic, and dis/order".
The stops are things like "graffiti" and "bus shelters" and "dancing" and "pigeons".
All of these had an impact on us as we did our work during the project.
We then went into our design implications section proper, which included the following subject areas that we thought were large enough forces at play that had shaped our thinking and influenced our rationale behind the design of the site.
Some you might easily guess if you were doing this project, others we found interesting and perhaps a bit surprising.
I'll highlight a sample one, so you can get a flavour of the document.
This one is titled "Jurisdictional Boundaries" and it's a design implication I believe is present for all levels of gov't (civic, regional, provincial, federal) to really improve upon.
Different levels of government are responsible for different aspects of our everyday lives. It is often not clear who is responsible for what.
Citizens are interested in who is responsible in order to seek action and resolution to a particular issue. They have a problem that needs resolution and want to find out who to contact.
The seemingly arbitrary bi-products of the design of government need to be clearly communicated to the citizen user, even if the responsibility for the service is not entirely that of the City’s. Examples of jurisdictional boundaries that affect citizens include transportation (City owns streets, TransLink runs the buses); animal control (stray dogs are City, stray cats are BCSPCA); and water (pipes are City, water itself is Metro Vancouver).
We'd certainly seen confusion about why users were coming to the City's website in the survey data "Answer: find bus schedules"—we thought the City had some responsibility for dealing with this issue. A design implication existed. And we tried to do something about it. In our wireframes we had paid some attention to these types of issues. This was an observation we deemed important, and attempted to highlight the implication for other classes of this occurrence that other designers might stumble across in their journey.
One of these on their own sounds simple. A couple of them manageable. 15 of them was a lot to juggle in our heads at any given time. We often referred to these in shorthand in the project as "it's the mandatory task dynamic again" or "yeah, that's a jurisdictional boundary thing."
In hindsight, we wished we could have developed these sooner to help guide our design process,
But as this lovely diagram demonstrates, design isn't always that straightforward...
So this Design Implications document was like our little post-card to ourselves and to our future selves (us and other designers) about what we'd seen in our journey from the past.
I'm nervous, excited, and a bit worried about the re-launch as you can imagine. When you invest a lot of your time and energy and self into a project as a designer you become really attached to your work—I think that's part of being a good designer and it's also risky if you're too close to it.
I hope it’s a success, users find what they are looking for, and it helps change the relationship that citizens have with the City. I believe in an effective public sector and I think, like Jess, that we have a great opportunity to work with them to make the public sector better.
And finally, I believe in the increasing importance of IA as a discipline, as it transforms into the medium independent / cross channel incarnation that Peter Morville just wrote about in the IA Journal. Because it's there that we can help hold up a new mirror to an organization and help see themselves in different ways.
In that way, we really are hopefully Designing Structures for Understanding—be it with our public sector institutions, our big C cities and little-c cities, and even somewhere along the way, ourselves.
Thanks for listening.