FactFinder Concept to 1.0: From a strategy and code prototype to awarded software in eight months
BlueStripe software was founded and venture funded to meet the needs of people managing complex, multi-tier, mixed (real and virtualized) server environments. The main user goals to meet were to understand systems and their dependencies, health, readiness for production, and, in the case of problems, find the part of the system with problem to get right specialist and tools brought to bear. (Production monitoring and alerting were not among the first priorities.)
I was hired in January, 2008 as an interaction designer and product manager to help the company meet these user goals with compelling software: to provide state-of-the-art interactions and visualizations. Early inspirations include Colin Ware’s Information Visualization: Perception for Design, Edward Tufte’s sparklines, and an ACM SIGCHI paper showing effective perception and decision-making on graphs as small as 12×12 pixels.
The main approach was to provide a map with data overlays and name/type browse and search. The map would be filterable filterable and prunable to focus on an application of interest and its dependencies. Here are sketches from February and March:
In April and May, PowerPoint mockups like these were used on visits with potential buyers and users to validate whether we were working on something valuable from their point of view.
Based on the promising feedback we received, we articulated an ordered list of release priorities for a first release, at the top if which were:
Worth a beta
Interesting to analysts/press
Able to be sold
Able to be used hands-on in staging and production.
With this release prioritization, we did quick development prioritization work with index cards. We were aiming for clarity and understanding, not formality.
As the development team started working to realize the mocked-up designs in working code, in the priority order we had set, we added visual design with a contractor.
I had hoped that we would find a way to render all of the performance and dependency information at once in the map, but realized that there was just too much, particularly for people new to the software to take in, so we emphasized one kind of performance or dependency information at a time under user control.
Here’s a June Fireworks mockup with visual design applied. We aimed for the chrome to be simple and muted for the data to emerge from it.
By August, here’s what a screenshot looked like with much of the visual design applied and some differences in controls:
We tried at software on site with potential customers and found that we needed to simplify even more and call even more attention to anomalies.
We shipped and debuted at VMWorld, with recognition: