Building Systems That Actually Fit the People Using Them
The Long Way of Information Ecologies Using Technology With Heart
I spent about three years working on a municipal records platform that was supposed to serve three very different user groups: city clerks who needed batch processing, small business owners who just wanted to file a single form quickly, and accessibility advocates who needed screen reader compatibility across every workflow. The initial build took six months and launched to about forty percent adoption in the first quarter. The second build, which we did differently, took eight months but hit seventy-eight percent adoption by month four. The difference wasn't the tech stack. It was how much time we actually spent mapping the information ecology before writing a single line of code. Information Ecologies Using Technology With Heart is really just a practical framing for what happens when you design digital systems around the actual relationships people have with their information, rather than around database schemas or feature checklists. It comes out of the work of Carolyn Panko and John Bell at UW Bothell, who observed that information systems don't exist in isolation. They exist within communities that have their own norms, communication patterns, and informal knowledge networks. When you ignore those things, you build something that technically works but functionally nobody wants to use. The "with heart" part is the part most implementations miss. It doesn't mean adding nicer colors or friendlier copy. It means acknowledging that information work is emotionally loaded. People lose their temper when they can't find a document they filed three months ago. They feel anxious when a form rejects their submission without a clear error message. They trust systems that anticipate their stress and refuse to build systems that add to it.
How to Actually Map an Information Ecology Before Building Anything
Start by identifying the actors. Not job titles, but actual roles. In my experience, a role like "small business owner" hides at least three distinct information behaviors depending on whether they run a retail shop, a consulting practice, or a food service business. Each one has different document types, different regulatory touchpoints, and different thresholds for what counts as an emergency. Interview them separately. Don't group them by demographics. Then map the information flows. Where does information enter the community? Where does it leave? What gets stored, what gets shared informally, and what gets discarded? I once worked on a healthcare scheduling system where the intake coordinators were sending appointment confirmations through a private email thread because the official system didn't support urgent same-day changes. The official workflow was designed for a world that didn't exist. The workaround was the actual system. We rebuilt around the workaround and reduced same-day scheduling errors by about sixty-two percent. The hardest part is figuring out what people won't tell you. They'll say they use the system every day. They won't tell you they also maintain a separate spreadsheet on their personal computer because the official system deleted their notes after ninety days. Find the shadow workflows. They're where the real requirements live. Budget at least two weeks for this phase on any project that touches more than five distinct user groups. If your timeline doesn't include it, you're already behind.
Design Decisions That Actually Reflect an Ecological Approach
Most teams jump straight to interface design. Skip that. Write down the information entities first. What are the core objects in this ecosystem? A patient record. A permit application. A service ticket. A case file. These aren't abstract categories. They're the things people care about losing, misplacing, or mishandling. Every design decision should trace back to how these entities move through the community. When I've seen this done well, the navigation isn't organized by department or function. It's organized by lifecycle. A permit goes through stages: inquiry, submission, review, revision, approval, issuance, renewal. The system mirrors that. Users always know what stage they're in and what happens next. This cuts support tickets by roughly half compared to category-based navigation in my experience, though the exact number depends on how complex the lifecycle actually is. Context matters enormously. An agricultural cooperative has completely different information needs than a legal aid clinic, even if both are managing case files. The cooperative needs seasonal timing awareness, weather-related delays, and supply chain connections. The clinic needs jurisdiction tracking, statute of limitations reminders, and referral chains. One template never covers both. Build the structure to adapt, not to constrain.
Get the Full Details
Where This Approach Breaks Down
The biggest pitfall is over-investigating. You can spend six months mapping an information ecology and still have built the wrong thing because the community changed while you were studying it. I saw a library digitization project where the metadata schema was perfect on paper and completely irrelevant to how the patrons actually searched. The librarians had updated their search behavior twice in eighteen months. The schema was built from interviews conducted twenty-seven months prior. We ended up ripping out the entire metadata layer and rebuilding it in eight weeks using live search log analysis instead of user interviews. Another failure mode is assuming every community wants the same level of transparency. Some groups function better with opaque workflows. A domestic violence support organization, for example, explicitly does not want users to see the internal routing of cases. They want the system to be simple on the surface and complex underneath. Pushing full ecological visibility onto that team would have been a security problem, not a design improvement. Sometimes "with heart" means protecting people from information they don't need to see. There's also a scaling problem. This approach works fine for communities of fifty to five thousand people. Beyond that, the ecology fragments into sub-ecologies that contradict each other. A university-wide records system isn't one information ecology. It's roughly twelve overlapping ones with different governance structures. Trying to flatten them into a single ecological model produces a system that satisfies no one. In those cases, build layer by layer. Start with the most coherent sub-ecology and expand outward.
Information Ecologies Using Technology With Heart as a Daily Practice
If you're going to do this work, start small. Pick one information flow in your organization and trace it from beginning to end. Write down every place it changes hands, every format it takes, every system it passes through. You'll probably find at least three places where information gets lost or duplicated. Fix one of them. Then do the same for another flow. After about six months of this, you'll have mapped enough of your organization's information ecology to build something that actually fits. The alternative is building another system that works on a whiteboard and frustrates everyone who has to use it. I've been on both sides of that equation. The ecological approach takes longer upfront and saves time consistently afterward. The whiteboard approach looks faster until it isn't.
