The last few years I've been developing private curriculum to teach information architecture and modeling to students at the University of Wisconsin-Milwaukee and professional students in paid workshops.
Practical Modeling Workshop - IA Summit 2015
Modeling for Clarity - IA Summit 2014
Developer vs. IA originally posted on The Understanding Group Blog on May 5, 2014
It is not often that I’m the web developer anymore. While I’ve never been a “real” developer (with formal training), I’ve built my fair share of websites before The Understanding Group.
As a front-end developer, I would take a PSD mockup (usually from a print designer) and build a pixel-perfect* website. These weren’t the kind of people interested in hearing that their design was anything but perfect. As long as the site loaded quickly and was accurate, my role as the “guy coding the site” was complete. So I would plug along with my blinders on churning out beautiful and structured HTML and CSS.
But I’m not a developer anymore, at least not professionally, and as an information architect, I have different priorities. My goal is to make things good for people who live on the Internet. Not just accurate and efficient because the person paying me said so. I’ve done a good job of over-writing my internal priorities from “Accurate Because They Said So” to “Good Because of Reasons.”
After working on a few small development projects, I’ve found myself challenged by these conflicting priorities: Good vs Accurate. Good vs Efficient.
Since I was assuming both of these roles, first I created high-level architectural plans. I avoided going into great detail because I was the one receiving the plans, so there was little value in taking the time to create them. Once I’d reached the point where I’d described enough of the system to start building it, I took off my information architect hat and donned the developer hat. I went about implementing the plans and building the technical structures necessary for the platform.
But then, since my instructions were incomplete, a question arose. The kind of thing that the architect should have documented in the instructions. The kind of thing that should be run past the architect and not left up to the developer. But…I am the architect. So, without taking off my developer hat, I pushed through and developed the most direct solution. I should have stepped back and surveyed the situation as an architect.
Which, of course, resulted in GARBAGE.
Developers and anyone in a human factors field think radically differently. The developer thinks about how to best translate a set of instructions to execution by a machine. Those with a focus on human factors work to make the machine serve the human, based on what the human actually wants to do. These tasks—solving a computer problem and solving a human problem—are fundamentally in conflict with one another. Each are furthering themselves by marginalizing the other.
Modeling for Clarity originally posted on The Understanding Group Blog on April 14, 2014
A few months ago, I sat down for breakfast with my year-and-a-half-old daughter, Eden, and she pointed at and said “banana,” one of the few words she knew at the time. Foolishly, I thought she wanted to eat a banana, so I got a banana and started peeling it. To my—and apparently her—horror, she started shrieking and saying “No! No! No!” After a brief pause of bewilderment, I got another banana and handed it to her un-peeled, and she proceeded to hold it up her ear and say, “Hello? Mimi?” She didn’t have the words to tell me she wanted to call her Grandma, so she used what she did know to communicate her desire.
While her verbal skills have vastly improved over the past couple months, she is still figuring out this language thing and uses iconic things to model her desire. It’s intuitive for us humans to use symbolic representations, or models, to help us articulate meaning when we don’t yet have the right words, we’ve been doing it all of our lives.
Modeling is my favorite tool for understanding a problem. I’ve found it to be very useful, so I’m going to share with you what I’ve learned along the way. First, like a good information architect, I’d like to be clear about what I mean when I say model. What I mean is a visual model, as opposed to a statistical model. And by “visual model,” I mean, in essence, “a picture, based on reality.” And when I say “reality,” I mean, what is true about a system or situation.
Pictures are pretty cool; they’re a foundational part of how we learn and they help us keep track of what is true so that we can better understand what we’re dealing with. We learn best when we are able to combine some linguistic and some non-linguistic interaction with new information. This is why the formal contextual design process involves interviews and note-taking, as well as dedicated time to sketch out what you’ve learned on paper. We can better understand complicated workflows and business processes if we are able to learn about them linguistically—being told verbally or in writing—and then take time to work out the relational implications of what we’ve been told in a spatial, visual medium.
We can only learn something if we have a clear path to it from what we already understand, which is why asking questions is another critical part of how we learn. We are able to build out from what we already understand by asking clarifying questions in an iterative cycle until we understand the whole. But it can quickly become hard to keep track of all the pieces you have unless you have a good system for it. A model is a documentation system that allows us to record and articulate our thoughts before we’re able to use the right words. And this is really nice, especially when you don’t really know much yet about the stuff you’re trying to document. (Not that any of us find ourselves in that situation ever.)
We can see examples of pictures being used for learning and models as documentations systems manifest all over our world. We’re all familiar with that strange devilry known as IKEA. I won’t get started on the phenomenon of that store, but I will say that the instructions they put out are fantastic. IKEA instructions are a documentation system that allows for a shallow understanding of what can be fairly complex furniture systems. A wiring diagram is another example of a way we visually document a very complex electrical system. And we document it so that its complexity can be better understood, not so that it can be reduced.
Please Don't Let Your Website Decay!
originally posted on The Understanding Group Blog on August 26, 2013
The now abandoned Michigan Central Station (MSC) sits as an icon of the Detroit that once was. In its day it was considered the transportation center of the area; the “Ellis Island” of Detroit, as it was the often the first place inside of Detroit encountered by visitors.
MSC sent out its last train in 1988 and has sat abandoned ever since. Being a train station it has many large un-barricaded entrances that allow people, read: looters, to come and go as they please. They have extracted nearly everything of value from the building, breaking windows and vandalizing what what isn’t of value.
When I hear the history of that building I immediately see parallels to a fear that I have when creating plans for a beautiful, complex, and meaningful website for which there is no set or planned governance; what is going to happen if they don’t take care of it? This fear never comes about because I think the owners don’t want to take care of it, but because it is hard to establish the proper website governance and maintenance protocols needed to do so and if they are not intentionally created and enforced, they will probably never exist.
There have been a couple half-baked attempts at restoring the former glory of MCS, none of which have ever come about. I’m not clear on the reasons behind these attempts falling through, but it’s not a stretch to imagine that the effort would be huge and the cost would be high.
Earlier this year it was noticed that five windows, randomly located, had been replaced. The owners of MCS have no idea where the windows came from as they did not order any work done on the structure. It is as if some vigilante stepped on the scene and has tried to make it better.
But have they?
MCS has hundreds of broken windows; if I were to guess, I’d say 1% of the windows are not broken, including the five new ones. Can an individual work on their own to restore and bring order to a broken system? What will keep the looters who broke the old windows from breaking the new ones?
As much as I loved reading about these windows just “appearing” as a beacon of hope for this old structure, I don’t believe that this kind of vigilante restoration will be sustainable or scalable to the entire structure. To the same tune, a content strategy needs to encompass the entire organization and needs to be thorough and planned, rather than be enacted in a guerrilla fashion. One person can’t solve a problem of long-term mis-management on their own. It is a lot harder to restore something in extreme dis-repair than to create a governance plan to ensure the dis-repair never occurs.
Get a content strategy with detailed governance while you plan your website. If you’ve already built your site, it’s not too late to establish these plans before you’re left with a hauntingly empty shell of an abandoned structure to far-gone for repair.
Making Good Places Out of Unruly Spaces
originally posted on The Understanding Group Blog on July 18, 2013
I’ve started to notice myself in situations where there is no clarity around what a partner’s digital space looks like today, both physically and digitally, yet the project is pressing forward to make a better digital place for tomorrow. Defining the space as it is today is a necessary initial step in establishing what the place should be in the future. It is the crux of why we do interviews, contextual inquiry, content audits, etc. But sometimes the spaces we need to get a grasp of are unwieldy and simple audits and interviews don’t reveal the whole picture because no one person has dwelled in the entire space, and so they don’t have the whole picture.
The first time I was involved in a partnership with an organization that did not know the extent of their web and information systems, I was a little surprised…and frustrated, as bits and pieces of new information and context kept rolling in, as our partners re-discovered them, throughout the project. After working with several organizations like this, it’s become obvious that this is not an uncommon issue.
Organizations often do not know all, or even most, of the stuff that makes up their web site. This is a common result of an organization made up of many motivated people all working to drive the business forward. While they may be in sync on the business front, they aren’t aware of the impact of changes to their digital space as it grows with the business. The digital space grows organically in order to serve the needs of the organization, but there is no understanding of the need to maintain a holistic vision of the connections of meaning embodied in the digital space.This organic, unplanned growth reminds me of the phenomena of the Winchester Mystery House (the construction and planning phenomena, not the supernatural phenomena). A giant mansion that was under construction for decades with no master plan, but instead additions upon additions were built. It’s said that people have gone missing inside due to its unending expanse and insensible layouts.
With this chaotic pattern of additions the space is composed of many siloed places, each addition has meaning, but there is no holistic meaning throughout the sum of the entire structure.
So what do we do when we are asked to take an unruly mansion of a website, preserve its existing functionality, and restructure it to be a holistic place with built in meaning and intentionality?
While the whole does not have a coherent meaning, the individual chunks do. But given the fragmented nature, uncovering the individual meanings is difficult. To keep track of the expanse, I’ve found myself modeling the chunks in relationship to one another to fully uncover whatever meaning there is so that we can be sure to carry forward any intentionality that was already there.
By creating artifacts and models of the current world that shows how pieces and players interact, we can begin having conversations around these artifacts to establish a shared understanding of the existing place that can be aligned upon, and carried forward by the organization to prevent unruly, uncharted growth in the future.