Dashboard design is a particular skill, requiring a strong focus on the user’s role to secure sustained adoption of the technology. Irrelevant key performance indicators (KPIs) mean irrelevant dashboards.
Design Guiding Principles
We follow a set of overarching guiding principles in our approach to designing dashboards as follows:
- Our underlying philosophy is to focus on the targeted delivery of a small group of KPIs relevant to a user’s role.
- Keep it simple and intuitive avoiding gimmicks that add no value
- Design dashboards that are fit for purpose – narrow in focus to be effective and not aim to cover too broad a dataset. Should enable managers to quickly and routinely comprehend how they are performing against their KPIs, not to provide an environment for complex data analysis
- Use familiar chart formats such as that users can easily relate to. The aim should be to communicate the data with as little visual “noise” as possible
- Make dashboards real by such as using geographic maps overlaid with BI data, use mashup capabilities to overlay measures etc.
- Avoid color alone for transmitting meaning – it could violate disability regulation in some countries and besides colors are perceived differently by different people
- Include experienced UI developer/layout specialist who understands human-machine interaction as part of the dashboard development team
JTSI’s AGILE dashboard development lifecycle
- Establish/Understand client’s Strategic Vision
- Establish long term vision and derive series of tactical milestone projects prioritized by pain points. Incremental delivery provides greater confidence and user engagement.
- Set proper stakeholders’ expectations, identify risks and timelines
- Determine scope, timelines and budget
- Project Prep
- Name project team members – must comprise of end users
- Set boundaries and project objectives
- Blue Print (Design)
- Requirements Gathering
- Gather initial high level requirements
- Create simple hand-drawn mock-ups to drive team-discussions
- Discuss with the business executive which decisions he/she wants to make for each business function. Then talk through the metrics that will enable those decisions
- Engage IT to determine feasibility of gathering data needed for metrics.
- Create a complete prototype to facilitate remaining discussions. Utilize Excel for data aggregation (if vendor software is not in place) followed by a vendor product based proto type
- Demo the proto type with IT and Business Executives to validate assumptions and elicit refinements
- Drive a detailed requirement sessions using the prototype.
- Iterative Development approach – During development, conduct 3-4 prototype sessions with users, where the business team can validate format and calculations. Have the business acceptance testers get raw data that they can manipulate and sum up to make sure the dashboards show what’s been intended.
- UI – Front End Development – closely work with the usability and graphics design teams, includes data grouping and summation needs, types and designs of visual alerts, kinds of interactive drilling to be made available
- Query implementation – Back-end integration, creations of queries to retrieve the requisite data elements from the appropriate data sources etc.
- User Authorization and Profiles – Design role-based security and authorization profiles
- Testing and Validation
- Validate the Dashboard with a cross-functional team – Soft Launch and let users experience the dashboard. It will become apparent that some metrics are unnecessary, while some are missing. We call this a “controlled go-live”
- Go Live
- Work with the IT and Mobile team to enable the dashboard through company authorized devices (mobile included)
- Enable extranet or portal access for partners and customers
- Maintain – Keep the development team engaged for 3 to 4 months for training and revisions.
- Requirements Gathering