Targeting Large Improvement with Small Changes

Before I started work on the redesign of our systems management software (described here), I worked in a small team of three (including two developers familiar with the code, one of whom had spent years working with our customers) to design and propose ways to improve the software to reduce the effort and likelihood of errors when deploying to manage a large environment.

We knew of other issues, but we decided that the best return on our time, our company’s development time and for our existing customers was to find ways to reduce the cost of deploying management to a large environment.

We brainstormed over the span of several days what the most important and common complaints were and what possible solutions we had for them. We picked a few that looked like they had low development costs and high value in terms of reducing customer cost.

We characterized costs of deployment in terms of the number of people over the number of days it would take to set up our system to manage and environment of a certain number of typical applications. We characterized where we were (it was, of course, an estimate at order-of-magnitude precision), what an imaginably-feasible goal would be (one person in fifteen minutes sets up management for an arbitrarily large environment), and then we looked at our alternatives in terms of how they would change this characterization.

Over the course of a couple of weeks, the three of us would meet and spend time, mostly at the whiteboard, figuring out at increasing levels of detail what relatively small changes could be made to the software to make significant improvements in the people:time:environment characterization. This was the first small and intense technical collaboration that I remember doing, and I remember being impressed at how the three people working together could get things done better than the three of us working separately as we were working on creative problem-solving.

Ultimately, we came up with three detailed proposals. Unfortunately, there was not room in the schedule as it existed to do any additional work before the upcoming release of the software, we had large concerns that the costs and risks of waiting on reducing the cost of deployment were much greater than the costs, risks and rewards of shipping the software a little bit later with substantially reduced deployment costs.

We made our case broadly and deeply, from impromptu hallway conversations to animated slide presentations to executives. In the end the executives decided to delay shipping for weeks and include two of the three proposed changes. A variant of the third proposed change was developed and shipped in a later release of the software. The thinking and design that went into the third proposal also informed and speeded the design work in the redesign effort.

After shipping we got feedback that, as we expected, while the changes seemed a bit awkward, they significantly reduced the cost of deploying the software into large environments, which meant that users were happier and that large sales had become easier.


Carl Seglem Interaction Design Logo

Carl Seglem Portfolio


Big Data, Enterprise, and Complex Systems

Lean & Agile