information architecture of the mundane

19
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. Information Architecture of the Mundane Michael Adcock

Upload: michael-adcock

Post on 16-Apr-2017

152 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: 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.

Information Architectureof the

Mundane

Michael Adcock

Page 2: Information Architecture of the Mundane

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

Page 3: Information Architecture of the Mundane

I thought about it, and decided to pull a Wurman. To look at the opposite, to better understand the issue.

Page 4: Information Architecture of the Mundane

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…

Page 5: Information Architecture of the Mundane

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

Page 6: Information Architecture of the Mundane

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.

Page 7: Information Architecture of the Mundane

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.

Page 8: Information Architecture of the Mundane

8

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.

Tech– Multiple sources; acquire, clean, merge

People– Egos and feelings

Information– Handle responsibly to safeguard meaning;

present

Issues

Page 9: Information Architecture of the Mundane

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

Page 10: Information Architecture of the Mundane

I want to remind you again that “mundane” in this case isn’t necessarily boringor 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 epicthing and it’s not meant to last. It’s meant to help inform short-term decisions.

Page 11: Information Architecture of the Mundane

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

Page 12: Information Architecture of the Mundane

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…

Page 13: Information Architecture of the Mundane

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.

Page 14: Information Architecture of the Mundane

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.

Page 15: Information Architecture of the Mundane

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!

Page 16: Information Architecture of the Mundane

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

Page 17: Information Architecture of the Mundane

17

Don’t make the decisions for you.

Each have flaws and hide certain information.

May be “good” if reveals possible/better strategies.

Similar to Data Structures in Computer Science?– Meaning Structures?

Artifacts, Deliverables, & Meaning Structures

Observations…

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.

Page 18: Information Architecture of the Mundane

18

Can you accomplish what you hoped?

Can you accomplish more than you anticipated?

When you interact with it, do you better understand something? And, because of that, can you accomplish more/better?

“Good” probably depends a lot on context.

What is “good”?

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.

Page 19: Information Architecture of the Mundane

19

These notions of “good” apply to building AND doing.

Building– IA results in better discussions and decisions

Doing– IA results in better actionable strategy

Building and Doing

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.