Here are some lessons learned about the art of prototyping and how to successfully integrate this activity in an on-going IT project.
Look before you leap
Be mindful of the urge to start modeling and prototyping dashboards to the business users too early in the process. You may think you are generating business engagement but you might also raise expectations to heights that will prove out of reach once the ascent begins.
Lesson 1: The double edge sword called "Wow Factor"
This is one key culprit that raises its head often enough. We all agree displaying a fancy looking dashboard full of gauges, tickers and lights will charm many execs, but you should also bear in mind that not all business people will like fancy looking dashboards that reminds them of their teenager's bedroom. In my opinion the older a person is the less he or she will like fancy displays. Even more so for Finance, Operation, Compliance, Legal and other number crunching departments. Efficient dashboard are often more subtle and nuanced, using color and highlights judiciously. "Wow" dashboards are more comets than reality, they zip through the sky. Everyone looks up, and then they dissolve. Opt for a more balanced approach starting with a blank page and adding what is necessary to represent the key processes using the right visuals based on sound best practices.
Lesson 2: Ignoring the Data Model
Prototyping without a sense of what data source will be available is like driving without a map. You can get lost or drive off a cliff. When prototyping with users and writing stories on the taskboard (in the case of Agile), be careful not to go into features that the data source won't possess. This is especially true to projects where the data warehouse is being designed as the dashboards are being built. Know the data model or better; keep a data architect with you during those stages of the design cycle. What sense is there in having fancy weather component in the dashboard if no data is planned to support it? Know before you propose.
Lesson 3: Ignoring the tool
Knowing the capabilities of the dashboard tool is also critical, especially if the prototype is built using another toolset. Key charting components and UI features, API capabilities and the like are also important in knowing what can be done out of the box, or would require complex API programming. When I do not know the tool, I like to sit down with a developer and have him explain it to me and how it integrates into the current application architecture. Just make sure to choose a vocal developer that has some client-facing skills and clearly explain what his role is during the meeting.
Lesson 4: You should indulge in Wireframing
With all the fancy tools out there, wireframing seems monotone and a rather old way of doing prototype work. I find this being an incorrect statement. First, most of the truly good prototyping work happens on a whiteboard with black and red markers which resembles wireframing. Next, I have come to notice that any prototype that looks even remotely polished will be judged as the final look of the product by the business users. So unless your prototype is close to the final look and feel, forget all the warning about it being a draft, users will wrap their mind around your "draft" and critique its look, not its functionalities, which is want we want.
I hope these tips will make your prototyping efforts be as productive as they should!