Case Study 04/04

TouchConfig Redesign.

The configuration application behind every deployment: where cameras, devices, sites, alert rules, schedules, and access roles are defined before any monitoring system goes live. Rebuilt from zero, and structured to scale with the product line.

Business challenge

Every deployment ran through one configuration tool, and the original was failing so badly that even the internal team avoided it, let alone the clients. The testing team dreaded opening it, and configuration went directly into the database rather than through the tool.

My authority

Owned the rebuild end to end while still a UI/UX Designer. Studied every screen of the failing tool before proposing it, made the case more than once before approval, and defined all three layout types and the plugin architecture.

Scale

200+ screens rebuilt onto three layout types. 28–34 enterprise deployments. 1,000,000+ records handled in production.

Outcome

The database workaround retired for good. The rebuild became the internal reference for how to structure a project, and stayed simple enough that even one developer can maintain every page.

More context Collapse context

My role UI/UX Designer → Senior Team Lead · proposed and led the rebuild in 2016 as a UI/UX Designer, then owned the configuration tool from that rebuild until I left, working across development, QA, and delivery · design system author · author of the architecture documentation developers built from.

Team One developer, Trupti, and a graphic designer. The system, component library, and in-project documentation later let any developer build new configuration modules from the documentation alone.

Stakeholders CTO · database team · QA · the developers who built on the system.

Duration ~6 months from forensic study to mature release, with the developer allocated part-time.

Scope at peak Three layout types covered every configuration need across the product line. New screens added from the documented template, with no new patterns required.

Architectural endurance 8+ years without a structural rebuild. Still the configuration backbone in production today.

Overview

The tool every deployment ran through.

TouchConfig is the configuration application every Intellve deployment passes through before any monitoring system goes live, where cameras, devices, sites, alert rules, schedules, and access roles are defined. When I took it on it was failing. I ran a forensic week, then rebuilt it from zero on a single structural insight.

That rebuild has carried 200+ configuration screens across 28 to 34 deployments for over eight years with no structural rebuild. The lesson I keep from it: study a system forensically before you propose the fix.

TouchConfig, the configuration layer behind every deployment.

Title Needed

Description Needed

The problem

A tool people worked around.

TouchConfig's original version was not improved, it was killed. The database team had stopped using it at the very first project, the Global Vipassana Pagoda, entering bulk configuration data directly into the database because the tool crashed so frequently that any other approach was faster and safer than trusting it. I watched experienced professionals react with involuntary dread when a task came back needing TouchConfig.

That response is the most important product-quality signal available: when skilled people find workarounds to avoid using a tool, the tool has failed. Patching it would have led to the same destination eventually, just more slowly. I argued the rebuild case three separate times before it was approved. The first two arguments were UX-framed and correct on the evidence. They did not land. The third argument was commercial: client credibility was at risk, delivery teams were using workarounds that scaled into liability. That one closed the debate.

Why the rebuild, not a patch

Leadership signal

Proposing to discard a working-but-broken tool and rebuild it from zero, while still carrying a UI/UX Designer title, is a leadership act before it is a design one. I made the case three times, and the version that won reframed a craft problem as a commercial risk. Reading which argument the room will actually move on is the job.

The research

One week. One insight.

I spent one week on a forensic study of the existing TouchConfig alongside one developer, Trupti, who had joined about a month before me. Every module. Every screen. Every flow. Every form field. The study was not about how the screens should look. It was about the structure underneath them: what configuration work actually is, and how little of it is truly different from one screen to the next.

Configuration work is form-heavy, list-heavy, and table-heavy. Its building blocks are finite and repetitive. From that week the architectural foundation of the whole rebuild emerged: every configuration need the platform would plausibly ever have could be served by three structural patterns. Table. List. Form-with-map. Not four, not ten. Three.

Systems thinking signal

The week was not spent cataloguing screens. It was spent finding the deep structure of configuration work itself, the level at which two hundred different screens turn out to be three repeating patterns. Designing the pattern rather than the page is what let the system scale for eight years on one decision.

The solution

Rebuilt from zero. Built to last.

The decision was to discard the old version entirely and rebuild from zero, on the three layout types the forensic week had found. What followed was less a redesign than a small system: a way to build any configuration screen consistently, and to keep building them without me.

Solution 01

The three layouts.

Type 01 · List 01

List layout

Entity-with-children. Master list on the left, detail on the right. Used for any configuration where a parent entity has a stable set of children being managed.

Where hierarchy is the primary constraint

Master data · categories, system modules

Type 02 · Table 02

Table layout

Flat collections at scale. Sortable, filterable, virtualised. The bulk-edit and bulk-import workflows live here. Replaced the SQL workarounds the database team had been using.

Where scale is the primary constraint

Records · devices, sites, users, alert rules

Type 03 · Form + Map 03

Form + Map layout

Geographic configuration. A form on the left, an interactive map on the right. Used wherever the configuration carries a location: sites, junctions, perimeters, response zones.

Where location is the primary constraint

Spatial · site setup, zones, junctions on a map

Every configuration screen the platform has ever needed fits one of three layouts. No fourth type was ever required.

200+

Pages

28–34

Deployments

Years

TouchConfig Form-with-Map layout in production — TouchConfig · Form-with-Map layout, device configuration placed on a satellite map

Three types, 200+ screens

The Form-with-Map layout, one of three structural patterns: a form on the left, a live map on the right, for anything that carries a location. Part of 200+ screens built from just three templates.

Solution 02

Built to be reused.

The rebuild began by removing the thing that had failed. The rigid open-source UI library came out entirely, replaced with standard WPF components styled through a custom design system I built with my graphic designer. The system was deliberately practical rather than theoretical: what every button, field, table, and error state looked like, the spacing and alignment rules, and the three layout types. Enough to build any screen consistently, and no more.

The structure mattered more than the styling. Each configuration module was built as a self-contained folder inside one project, sharing a common component library and a single database layer. Adding a new module meant creating a folder and following the template, with no change to anything already built. The rules lived in documentation kept inside the project itself, the first thing a developer saw on opening it: the folder conventions, the three layouts and when to use each, the component library, and the standard for adding a module cleanly. This was the decision that made the system maintainable by people who were never in the room.

The developer was allocated part-time so the live POC and project pipeline was never disturbed. The first working version, every existing module rebuilt from scratch, was delivered in three months. By six months it was mature and stable, and the company moved off the old tool entirely. The capabilities the broken version could never have carried, bulk operations at enterprise scale, came later, once real deployments proved the need.

Leadership signal

Embedding the documentation and the plug-in structure inside the project was a deliberate choice to make the system independent of any single person, including me. A rebuild that needs its author present to survive is not finished. One built to be maintained by people who were never in the room is.

Solution 03

Bulk operations at scale.

Bulk operations were not part of the original rebuild. They were added after the first two deployments proved the need. The Global Vipassana Pagoda had its data loaded straight into the database because the old tool could not cope, and Thane Police, the first client on the new TouchConfig, still needed a direct load for its opening bulk of cameras and sites. The pattern was clear after that: every enterprise deployment would arrive with thousands of records, and no one would enter them one form at a time. These were capabilities I defined and scoped, not features requested from a backlog.

Bulk Add

Delivery teams configuring 3,500+ branch locations or 50,000+ ATM sites cannot do this record by record through forms. A template-based Excel upload was built. The decision that made it genuinely usable at scale: when records failed, the system generated a file containing only the failed records with the reason for each failure. Not a count of failures. The actual records, downloadable, fixable, re-uploadable. Telling a user that 47 of 10,000 records failed without showing which 47 creates an operational dead end at enterprise scale.

Bulk Edit

Selection that showed at all times exactly how many records were selected, making the distinction between "all on this page" and "all 10,000 matching this filter" explicit and visible before any action was taken. The same pattern was later carried directly into MonitoringHub's Data Access Group management. A decision made for configuration management in 2016 was still solving the same problem in a different product in 2023.

Solution 04

When scale broke the filter.

As specific large clients grew past the scale the system was designed for, the cascading dropdown filter degraded. It stayed usable to around 35,000 records, turned sluggish through the hundreds of thousands, and at one client running 1.2 million records, timed across several runs, it froze the screen for thirteen to sixteen minutes on a single filter change. It never crashed; it simply stopped being usable. I did not optimise the dropdown. I replaced it. The drag-and-drop filter system I designed allowed users to construct their filter chain in any order they needed, at any hierarchical level, without the rigid linear dependency of the dropdown chain.

I added a Load button, deliberate friction, because automatic loading on a dataset of 1,000,000 records would have crashed the system. The user confirms when they are ready to fetch data. They are never surprised by a system hang. Then I worked with the development team on virtualised pagination: load 500 records, recycle memory as the user navigates forward, pre-fetch contextually when the user jumps to a specific page.

The team had not built memory-managed pagination before, so I worked through it with them iteratively, demonstrating the approach using examples from comparable systems, answering questions in whiteboarding sessions, reviewing the implementation at each step. Load time went from 13–16 minutes to near-instant. The system now handles 1,000,000+ records. The same logic was carried forward into MonitoringHub.

TouchConfig drag-and-drop filter — TouchConfig · Multi-level selection across account, site, zone, and device, configuration at scale

13min

Load time before rebuild

0sec

Load time after

The impact

Eight years. Zero structural change.

The outcome

The numbers.

Layout types

The architectural decision itself. Documented, taught, and adhered to across the platform's full product line.

200 +

Configuration screens

Built from the three documented patterns. New screens added consistently for 8+ years without architectural strain.

8+ yrs

Architecture endurance

No structural rebuild required as the product scaled. Decisions that hold for eight years are correct decisions.

13 min → 0

Filter load time

From 13–16 minute hangs at scale to near-instant. Architecture still handles 1,000,000+ records in production.

1M+

Records in production

The architecture still handles datasets past a million, the scale that broke the original tool, without a structural change.

28 +

Active deployments at departure

Each a live enterprise client with unique configuration datasets from hundreds to over one million records.

The test of architectural authority

Duration under change, not approval at launch.

Eight years is the proof. The system absorbed new modules, new product lines, new client deployments, and new team members without a structural rebuild. That is the only meaningful test of an architectural decision: whether it survives the conditions it could not have predicted. Today a single front-end developer maintains all 200+ configuration pages from the documentation alone, years after I left.

Before / after

What changed structurally.

Before

After

Database team entering bulk configuration data directly in SQL to avoid the tool

Delivery team self-service through Excel bulk upload at any scale

Testing team visibly dreading any task that required opening TouchConfig

Tool invisible: works reliably, no incidents in 8+ years

Deployments bottlenecked by database team availability

Deployments self-sufficient: delivery teams operate independently

Crashes during normal use

STQC and RDSO certified. No crashes as a recurring issue since rebuild

No design system, no documentation, no plugin structure

Full design system, in-project documentation, plugin architecture. New modules added by developers independently from the template

Constraints

The limits I'd scope earlier.

Bulk Add belonged in the original scope.

The first two commercial deployments hit the exact bottleneck Bulk Add later solved: thousands of sites and devices, entered one form at a time. The need was foreseeable from the nature of enterprise configuration. It should have been in the six-month rebuild, not added once the pain had been proven.

I designed for the data that already existed.

The cascading filter was correct for the scale in front of us, around 35,000 records. But a platform gaining an enterprise client every quarter was always going to outgrow that. Designing for the visible scale instead of the coming one is what forced the filter rebuild later.

The commercial case should have been the opening argument.

I proposed the rebuild more than once on design and usability grounds, and it did not move. What closed it was commercial: shipping a tool in that state to paying clients put credibility at risk. That was just as true the first time. Leading with the business risk, not the craft, would have saved months.

The documentation should have been excellent in month one.

It became excellent by year three. For the first eighteen months, onboarding a new developer cost more than it needed to, because the guide was still catching up to the system. Documentation is a one-time cost; onboarding without it compounds every time. I underweighted it at launch.

Leadership signal

The architectural decision only a leader makes.

What a ground-up rebuild reveals about judgment under constraint.

I killed a product rather than patch it.

Patching the existing TouchConfig was the safer organisational decision. Killing it was the right product decision. Knowing when to kill, and defending that case to leadership, is the work no IC is positioned to do.

I held the line at three layout types.

Every module owner wanted a fourth layout for their special case. I said no, repeatedly, with the documented case for why the existing three would handle it. Constraints, defended, become productivity. Constraints abandoned become entropy.

I made the system survive me.

A design system passes its real test when developers ship new configuration modules from the documentation alone, with its author nowhere in the room. The work I did in 2016 is still operating without me in 2026, structured so that even one developer can keep every page across every deployment running. Leadership in design is building systems that outlast their author.

Read all twelve principles How I lead