At the time of this project, the software development industry was in the process of growing and maturing to become an integral part of all companies, not just software companies. Application Lifecycle Management (ALM) emerged as a new concept model for labeling and tracking the lifecycle of software development.
Collabnet Enterprise (CEE) already had full-featured tools for the developers, but they were “silos,” and there was no insight into what was happening in those tools.
As a step in product maturation to embrace ALM and address a gap in the feature set, Project Metrics was conceived and designed as a new integrated capability to generate reports and visualizations of key project activity metrics for project/product managers and project team members (developers, testers, and observers).
Limited in scope, the project metrics design concept was not defined to be an all-inclusive reporting tool, and it was not intended to replace either stand-alone reporting applications or Excel (there was a separate effort to build an api for external tools).
Instead, it was just-enough reporting on pre-defined metrics, primarily for project/product managers who were already creating reports and charts manually for the rest of the team and stakeholders.
There were two main challenges to Project Metrics:
Since the scope of the reporting and measurements was constrained, the creation process could be distilled down to a wizard pattern with three steps:
Within the creation wizard, as each step was submitted, the choices available in the next step dynamically updated for the user, offering only options that were appropriate for the preceding choices. This reduced the task to be as simple as possible, making the sequence fast and easy for any user.
Furthermore, it neatly benefitted the overall product experience because misconfiguration and incompatible selections were “designed out.” A report could return zero results and that would be a valid report (e.g. there are no open issues this week). But an invalid report that returned errors could not be created.
Ad-hoc reports are necessary so that a person can make an inquiry on-the-fly, and this was capability was provided with the “Instant Report” action.
But people do not want to have to go through the process of defining a report every time they want to see the results. That would be absurd. So it is a foregone conclusion and a user experience requirement that if reports are a feature of an application, then it must be possible to save a report and run it later, repeatedly.
Initial design proposals took this in the typical direction by considering a report file, or document, with the functions to manage files. And promptly abandoned this path.
Designing (and building) an entire file management system for reports, with all of the concomitant tasks for such a system (save, copy, delete, naming, permission checks, error handling, and so on) was not in scope. Nor was it desirable. That is not where the value resided.
A concept was needed that would avoid the conventional requirements of a file management tool and still provide the capability that users expected: define a report and save it in a project.
The solution invented was to subvert the expectations of a report and focus on the goal of the user — viewing the report results.
Within CEE, project spaces had a lightweight template-based publishing system for creating project content, like meeting notes or status information, that would be part of the communal project site.
Project metrics seized on this by devising and designing a new report module, or page component, in the publishing system. The module could be added to any page, and it displayed on the page separate from any other free-form text/content. What the module really did was to define a “space” — a receptacle or container — where a report could exist. One container = one report. Ten reports? A page with ten containers.
This transformed the entire idea of what reports are and how they are saved. A metrics report became intrinsically linked to the project communications.
When a new report module was added to a page, it was empty, and the chart image displayed a message that it did not have a definition.
Clicking the empty chart brings the users to the report definition wizard, and when that (short) process is complete, the report chart displays. This behavior is exactly like the instant report, except that now the chart has an action available to store the report. Nothing more is necessary. The user is returned to the original page, and what was previously empty now displays the new report.
A complete set of user flows was designed, mapping out the overall flow and architecture of the tool, and how the new features would integrate into the existing system.
Working hand-in-hand with the user flow maps, the interactive prototypes tangibly demonstrate the interactions and behaviors of the application.
In this project, the prototypes were the primary design deliverables and were the focus of discussion. Built in HTML, the first prototypes were low fidelity. After a cycle of feedback and review with the entire team, the design was developed further, the fidelity level increased, and the review process repeated.
After five cycles of discussion and review, the design was finalized and the prototype was rebuilt to incorporate the application’s real design language, making it into a living reference specification and a production-ready resource. This provided a shared reference for everyone on the team, improving communications and reducing engineering time.