Whenever I visit my family, I always dread the inevitable question: “So how’s work? What do you do again?”I then go through the usual script:
Me: “I’m an information architect at a software company.”
Uncle: “So you do all the coding?”
“No, it’s more like designing.”
“Like Photoshop? Didn’t you go to library school?”
“Well, yeah, but…”
“I design processes.”
(more confused silence)
“So how’s New York treating you?...”
I have always opted for the hard-to-explain jobs, but information architecture is by far the most confusing to the uninitiated. It’s not easy to sum up the totality of information architecture in a one-minute conversation. As is often the case with “big picture” jobs, there’s no tidy way to say: “I think of all the pieces that make up a thing and how all the pieces and things interact and affect each other, and make sure they all play nice with each other and make sense to people.” However, there is a term for that, and it’s called systems thinking. Very simply put, systems thinking is this:
Everything affects everything else. That’s it! Well, kind of…
Is everything a system? The snarky answer from those who may have recently read James Gleick’s “Chaos” or watched Carl Sagan explain how to make an apple pie would be “yes, of course.” Everything is connected. While that may be true, the scope of that size is just too daunting. This is the problem with systems: they very easily get very, very complex. The skill in systems thinking is determining how far to zoom out (or in).
So, how does one know “whether you are looking at a system or just a bunch of stuff?” asked Donella Meadows, the late environmental scientist, wrote in her pioneering book, “Thinking in Systems: A Primer.”
Meadows outlines a few questions you should ask when looking at a potential system (paraphrased below):
1. Can you identify all the parts?
2. Do the parts affect each other?
3. When you bring the parts together, do they produce an outcome that is different than when you experience the parts individually?
This evaluation method has been invaluable in my current project for Infor HCM, in which we were challenged to completely overhaul the entire Human Capital Management system that’s chock full of “parts:” - human resources, succession planning, performance reviews, benefits enrollment, time tracking, and so on. Our main goal was to make this system work, well, more like a system. A true system.
We had identified all the parts of the HCM system, but in order to work effectively and not be overwhelmed by the scope, we could really only work on one sub-system at time. However, as we found out, nothing exists in a vacuum. Let’s look at one of those sub-systems: performance reviews. User interviews had told us that, for myriad reasons, everyone dreads doing annual reviews. We worked to mitigate that dread by incorporating new features like frequent check-ins and goal setting, but also by incorporating features from another sub-system: time tracking. We thought, what if a manager could see a summary of an employee’s time record on a certain project? Could that be useful in determining a performance review and ultimately a raise or promotion? We decided that if the actual time tracking data could not influence a subjective employee appraisal, we could at least make that data available to a manager in order to provide them with more information on that employee. One of the biggest pain-points in doing annual reviews is that the user has to remember or look up everything an employee did over the last year. The more information we could surface during this process, the better.
While working on this project we constantly had to keep two thoughts in our head: is this something that can be solved by software or by people? Where do the two intersect? Ultimately, the HCM project is about people and whether or not those people are happy and satisfied by their work. A half-hearted performance review - done simply to get it out of the way – does nothing to better the employee or manager’s experience in the workplace. We found that by fixing the software side of the review, the people could then complete the once dreaded task with ease.
When working with software systems, it is important to keep in mind that one of the parts of the system is the human using it. When the user is frustrated, the system breaks down. By fixing the software, and seeing how all the parts fit together, we can actually increase the user’s happiness and make a healthy functioning system.
Meadows, D., & Wright, D. (2008). Thinking in systems: A primer. White River Junction, Vt.: Chelsea Green Pub.
Meadows, D. (1997, January 1). Leverage Points: Places to Intervene in a System. Retrieved April 6, 2015, from http://www.donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/