On Tending the Garden (and Fighting Kudzu IA)
I was presenting to a client, talking through my discovery work. They were a good organization, with good people and a good ethos, but they suffered from what I’ve come to call “kudzu IA.”
Kudzu, the weed that ate the South. The US government introduced it during the 19th and 20th century for soil erosion control. It had appeal as an ornamental. And then it got loose in the warm, frost-free southeastern United States, rapidly becoming a noxious weed that would cover everything: abandoned homes, barns, trees.
Given room to spread, kudzu IA can engulf structures.
I first coined “Kudzu IA” when I was working for an enterprise startup. As the client’s business grew and changed, it added new items to the flagship product, following the contours of the business goals. And it kept growing, following those business contours, following them until there was no structure to the site but the historical whims of the organization. Feature bloat obscured context and meaning. The information architecture took on the unsupported, wild, all-directional spread of kudzu.
“Kudzu IA” becomes a cognitive tangle for users and customers to follow. When you ask people to understand the maze of links presented to them, needless complexity turns into needless cognitive load. User confusion comes out in the analytics. You find users pogoing between pages trying to fulfill their goals. Eventually, they give up.
For a long time that was my view of how these systems get out of control — they grow until they’re unsupportable. Feature bloat, wild hairs, make-do solutions pile up until the IA collapses like a rotting trellis trying to hold up an overgrown vine.
Recently, though, I ran into something during user research that made me question if that is always the reason things get out of control and abandoned.
I was interviewing enterprise users about how they managed their data, from the CDOs in the boardroom down to data stewards who made sure the data was available in the right way for the right people. They described problems similar to what I’d call “kudzu” — complicated knowledge paths, half-finished solutions, and divisions within the company building their own data islands because they didn’t trust the company-wide data solution.
They never intended to grow kudzu, though. They started out solving their data problems with well-planned projects, put their best people on them, hired good consultants, and put real capital behind them. They weren’t trying to create kudzu; what they were trying to do was plant orderly gardens of data and structure.
And what happens? I would describe it as “gardens gone wild.”
Twenty years ago on my honeymoon (yes, I’m that old), we went to Victoria, British Columbia. A few kilometers up the road is Butchart Gardens – a large, formal garden built out of an old cement quarry. It’s sprawling, classical. It mixes Asian and European garden styles in with local plants, and the owners try hard to provide a trained and structured view of the world amidst the great cedar and fern forests of the Coast Salish lands. To keep it like this requires a lot of effort, of course, and entry tickets are priced as such.
The owners have a lot of motivation to keep the garden tended. If it goes unkempt, people will stop buying tickets.
That’s the thing about gardens: You have to maintain them. If you don’t, you’ll get weeds, you’ll get invasives like kudzu, your manicured plots get overgrown and overrun, and horticulture you intended to see there will fade from view. People will stop using them, and all you can do then is tear everything out and start over (assuming you have the capital).
Maintaining structures takes effort and resources. Tend your garden.
In my user interviews, the data experts told me about projects done, projects abandoned, and the endless tension between keeping a system up versus attacking new initiatives.
They talked of one common scenario: The project with no maintenance budget. There would be a huge project launch, urged on by some senior member of the organization. The company would put money, resources, people into the project. And once done and delivered, people would use the delivered resources… for a while, at least. Eventually, it would fade into the other sets of tools they have in use. One day, someone would find a bug or an error and try to report it, only to discover there’s no team to report it to, and there’s no one who can fix it in a timely fashion.
Kudzu, for them, was a way of life. All it took was people not being motivated to keep it up. And the motivation always wavered as priorities shifted and day-to-day work demands took precedence.
Occasionally there will be some rationalization for how it This Time It Will Be Different. “We can crowdsource it! We can instrument it! We can treat it as a wiki!” But in nearly every case, these organizations don’t leave behind money, resources, and people hours to maintain the data they already have. They depend on the goodwill of the users to handle maintenance, but those users have their own jobs to do first. The system slowly degrades like an unweeded garden until eventually, it loses form and use.
So, it seems to me that kudzu IA isn’t just about having an unstructured, unplanned way of building out your products and content; it’s also about not putting the effort into following through on your plans to keep your IA groomed and up to date. In both cases, in fact, it seems that maintenance — “tending the garden” — is essential to ensuring that the best possible experience comes through for your users. You have to invest in maintenance as much as you invest in planning.
The only way to fight back against kudzu in your services is hiring gardeners who can curate, maintain, adjust, and improve continuously. This means the organization has to invest in these gardeners and give them the tools they need (like operationalization, instrumentation, and management tools) along with the resources needed to use those tools on a regular, continual basis.
It also means putting the constant effort into auditing, measuring, testing, reviewing, updating, and sunsetting. There need to be people who look at content and features, review their usage metrics, consider the problems these things are trying to solve and whether they are still getting solved effectively, test whether they still make sense, and then rewrite, renovate, or even just kill outright.
That effort has to be constant, and it requires actual people to do the gardening. Sure, AI and bots and scripts and feedback mechanisms can help, but at the end of the day, there has to be a human or set of humans somewhere who is accountable for keeping things tidy and functional. Machines can’t do the work of tending unless someone can tell the machines what to do when — and when not to do it. And this isn’t just a UX function in a company; it’s essential to the business, too, and so the work has to extend to product managers, content strategists, and even leadership.
Personally, I’m tired of encountering kudzu IA. I mean, it’s paid my bills the last decade-plus, so it’s quite profitable to the UX professional. But it’s preventable, simply by putting the effort into maintaining what you have already. Admittedly, maintenance doesn’t get ambitious mid-level managers the splashy projects they need to beeline to the C-suite. But the kudzu these splashy projects leave behind becomes my problem, and even worse, it becomes the problem of everyone in an organization.
Fight kudzu. Tend your garden.
