1. Context: The “User Gap”. We have built a Big Data platform for the City Hall of Fortaleza, State of Ceará, Brazil, designed to integrate health and education data to support “First Childhood” policies. The goal was to help public managers answer critical questions, such as the demand for daycare vacancies. Technically, we were succeeding; we had defined requirements using “Data Canvas” workshops and delivered an MVP. However, we hit a constraint familiar to many government agile teams: The User Gap. As we moved to validate the monitoring dashboard, we faced strict time limitations and an inability to schedule synchronous sessions with the end-users (public managers). This created a dangerous risk. As noted in our analysis, usability flaws in data products can become barriers to adoption. We faced the prospect of delivering a dashboard that was technically sound but practically abandoned because managers couldn’t interpret the data. We needed a method to validate the interface now, without access to our users.
2. What We Tried: “Hacking” the Heuristics. We pivoted to Heuristic Evaluation (HE) as a proxy for user testing. We knew generic heuristics (like Nielsen’s) were insufficient for the complexity of our data, so we selected a specialized checklist for data visualization (Dowding et al.) from medical literature. However, applying this academic tool in a real-world government project was not plug-and-play. We had to “hack” the methodology to fit our reality: Breaking the Binary: The checklist was rigid, offering only “Yes/No” options. We found this binary grading failed to capture the nuance of our software. We forced the tool to accept a “Partial” status by marking both “Yes” and “No” simultaneously on the forms—a manual workaround to reflect reality. The “Consolidation” Check: We brought in an external expert to inspect the interface alongside our internal team. We established a “consolidation meeting” to review every item, anticipating that two different evaluators would see the interface differently.
3. What Happened: Friction and Findings. The process was not just a procedural check; it was a struggle to align different mental models. The Interpretative Friction: During the consolidation meeting, we faced the “subjectivity trap” noted in our lessons learned. Items like “Is the visual layout well designed?” triggered debate because they were open to interpretation. We found ourselves struggling to align our internal definitions of “quality” against the checklist’s vague academic standards. Furthermore, the tool was in English while our context was Portuguese, creating a cognitive load where we had to mentally translate technical concepts on the fly. We were fighting the tool as much as we were fixing the software. The “Invisible” Flaws: Despite the friction, the inspection caught 13 specific usability leaks that would have frustrated our users: The “Analysis” Trap: We had labeled a key section “Analyses” (a technical term). The evaluation highlighted that this was confusing for managers who simply wanted “Visualizations.” The Search Blind Spot: We assumed our map search bar was obvious. The inspection revealed it had “little prominence” and the placeholder text didn’t clear upon clicking—a small friction that stops a busy manager in their tracks. The “Click vs. Hover” Guessing Game: We found we were inconsistent with data tooltips—some required a click, others a hover. We were forcing users to guess how to retrieve information.
4. Learning & Implications. Our internal beliefs about quality assurance in government projects shifted during this experience. We learned that data teams unconsciously design for themselves. The “Analysis” vs. “Visualization” naming error was a wake-up call. Without users in the room to correct us, we projected our own technical mental models onto the interface. Heuristic Evaluation acted as the necessary “check” to reveal this bias before release. We learned that Heuristic Evaluation is a political shield. We used to view HE as a “discount” method. We now see it as a vital filter for high-stakes environments. By catching 13 friction points (including 3 major ones) before a single manager saw the screen, we protected the project’s credibility and prevented the “barrier to adoption” risk. We learned that Data Products need more than Nielsen. If you are building for decision support, you need heuristics that audit the interpretation of data, not just the navigation of the page. Standard usability checks would have missed the semantic issues in our dashboards (like the lack of color coding for positive/negative data). Who is this for? This approach is specifically for teams in high-constraint environments (government, enterprise, regulated industries) where end-users are politically important but physically inaccessible. If you have direct access to your users, you should simply talk to them. But if you are “designing blind,” adapting specialized heuristics can be the difference between a launched product and an abandoned one.

Presentation Deck