Information Architecture of the Mundane
As I thought about the Discussion of Masterworks at the 2016 IA Summit, it kinda bugged me. Because our reason for discussing the masterworks of IA is to figure out what good means and to help us critique.
But it bugged me because my impression of what a “masterwork” might be is something like Wurman’s Tokyo transit map. Something epic. Something that is artistic and cool enough (to designers, at least), that it rises above its original purpose and outlasts it somehow. It’s something timeless that we put on a pedestal.
And while that’s fine, I’m not sure we’ll come to a better understanding of good if we only focus on stuff like that. There should also be good in regular day to day stuff because that’s why we’re discussing this. We want to figure out how to do our work better, and better understand when we do.
I thought about it, and decided to pull a Wurman. To look at the opposite, to better understand the issue.
And that’s the basis of my discussion here: Information Architecture of the Mundane. While “mundane” may not be opposite of “masterwork”, I’m relying on the temporal and earthly connotations, as opposed to the timeless reverence associated with a masterwork.
I wanted to discuss an example or two from my own work. But I realized that everything required a lot of context and set up. There are things you’d need to know about ProQuest’s customers, business, tech, and even political stuff in the company. It all got too big and too unmanageable to discuss here.
I needed something simple and easy to recognize. And it needed to be something measurable. I needed to have proof that it is good in some sense. And then it hit me…
…the pinball league stuff I’ve been doing for our team.
The data is simple. It’s players, machines, locations, and wins/losses, along with a smaller subset of scores. But like my actual work stuff, it hits on all the aspects I needed: tech, people, and information.
There are tech issues. The data comes from many sources/sites and must be collected, cleaned, and merged. It’s too much for a person to do manually, but with some scripting, code, and tools… technology can help.
There are people issues. My team needed to be able to read and understand the artifacts I made. But they are also people with feelings and egos and such. I made decisions based on that. For example, people want to know how they are playing, but they don’t want their faces rubbed in their failures. So I was selective when sharing player performance info.
And of course there are information issues. Both in terms of cleaning the data responsibly to ensure its correctness of meaning, and also in how I presented it.
Sure, on the surface, it might look like I’m just doing some kind of stats thing or visualization stuff. But those are just small parts of an entire information architecture I created. The IA isn’t the artifacts, and it isn’t the strategy. It’s the system of things that led to a discussion about strategy. It’s something that could help us come up with a better strategy, based on what we understood.
I want to remind you again that “mundane” in this case isn’t necessarily boring or dull, but is temporal. The pinball stuff I’m doing is something that is literally thrown away each week. Sure, I built a process to save myself time when I generate it. But the artifacts I create help inform us for the next week’s game (and to a lesser degree, review the previous week). It’s not some kind of epic thing and it’s not meant to last. It’s meant to help inform short-term decisions.
Which, coincidentally, is at least some of the work I was doing at ProQuest! Helping inform, sometimes critical, short-term decisions that might have lasting effects. I wasn’t just providing good information like a corporate librarian might. I was providing tools and artifacts to help people understand that information. Ad-hoc, skunkworks, all these terms were mentioned in regards to what I was doing at work, and they apply equally well to my pinball hobby IA.
As for the proof of goodness… Our team has mostly consisted of the same players each season. (We’ve lost one or two and only gained a few new folks.) And we’re all arguably improving as pinball players, due to practice and interest. But all that aside…
The first season we played without any of this IA stuff, we just did ok. The second season I started experimenting with some of this, but it was much less refined. We made it into the finals, which was kind of an upset.
We also beat one of the top teams at their home location, which hadn’t been done before! Other more established teams were asking where we came from and how we improved so fast.
Our third season, after I had time to refine my pinball IA, we didn’t just make it into the finals, we earned second place out of all 12 teams in the league!
That’s when folks couldn’t help but take notice of us. We’d improved as players, but not by that much. Instead, we were playing smarter with our machine and player picks. Our “stats” informed us and provided understanding which we used to make better decisions. But we were still playing for fun (that was a design criteria!) People still get to play what they want to play. The big difference was that most other teams were only playing for fun and choosing randomly. We’re in our fourth season now, and secured our spot in the finals. (Sadly, this was done without me, as I was already in Atlanta for the IA Summit!) There are 16 teams in the league and we have a good shot at earning second place again, and maybe even first. Whatever goodness is in my pinball IA hasn’t just pushed us to play better. It’s encouraged other teams to find ways to play strategically as well. And we’re all becoming better players as a result.
The artifacts and information I produced was not meant to make decisions for us. I made it to reveal things and help us understand better, but it was up to us to decide how to act. It was a thing to discuss, and it made us aware of patterns and potential strengths and weaknesses. But it has flaws, and hides certain information, and it’s up to us to figure out how to make use of it the best way. It doesn’t provide a strategy, but if it’s good, it will reveal possible strategies, and perhaps even the best strategies.
I’ve also been struggling with the words “artifact” and “deliverable” and wondering what these things actually are that we all produce. While this is a subject for another talk, I think we might be able to borrow a related concept from Computer Science: data structures. But what we are inventing, using, and re-working are (maybe?) meaning structures instead of data structures. I see parallels and would love to discuss. And maybe it’s a better term for the connotationally difficult names we already use.
I think the masterwork stuff has more to do with the subject matter and intended use than it does with the quality of the IA. Wurman didn’t accidentally make something epic with that Tokyo map. I think the mundane-epic spectrum is a distraction.
To me the good of an information architecture is about whether it helps the people using it not only accomplish what they hoped, but perhaps accomplish even more than they could have anticipated at the time it was proposed. It enables the people who interact with it to better understand something and be able to accomplish more, and accomplish better.
The main reason I pitched this presentation was to make sure as a group, we’re not too focused on the “masterworks” part of the discussion. Instead we should focus on identifying what good means. I suspect a lot of what good actually means is dependent on the context and issues a particular information architecture was created to help solve.
This should apply to information architecture that helps people build a product, website, app, or whatever. I’d hope that better discussions and decisions around the building of things are fostered by better IA! But it also applies to something that is intended only to aid in strategy. How to determine goodness shouldn’t depend on whether it’s IA in support of building something, or IA in support of doing something. Maybe that’s one distinction between “built” architecture and information architecture. You can do IA with the sole intent being to better inform decisions and strategy.