Dashboard Development Life Cycle

Dashboard Development Lifecycle

1

Dashboard development lifecycle

Define Purpose and Objectives

Activities	Considerations	Guiding Questions	Best Practices
Define the specific decisions the tool must support	Concrete use cases for the dashboard help prevent scope creep and ensure that the final product answers practitioners’ questions. For example, “Improve postsecondary outcomes” is a goal, but “What high school course-taking patterns correlate with higher rates of postsecondary enrollment and retention?” is a more concrete question for a dashboard to answer.	What is one decision that users will make with this dashboard that they cannot make today? How long should it take users to find the answer?	Add clarity to the dashboard scope by defining inputs (We will include data from the National Student Clearinghouse (NSC), statewide longitudinal data system (SLDS), and Free Application for Federal Student Aid (FAFSA) and outcomes for users (“A counselor will be able to identify in 2 minutes which high school seniors have not completed the FAFSA”).
Map policy questions to metrics	Before looking at specific data, determine what metrics will answer users' questions and the data needed for those metrics. Identify and address any data gaps so that the dashboard is built around relevant information, not just the data you happen to have available.	What are the 3–5 most important questions this tool must answer? For each question, what data elements are required? Are those elements available, accessible, and comparable?	Avoid selecting metrics solely based on information already in the data warehouse without confirming that those metrics support real decisions.
Define guiding principles for dashboard governance	Governance should reflect the organization's values around transparency, consistency, privacy, equity, and responsible data use. Shared principles help resolve future disagreements and maintain stakeholder trust.	What principles will guide dashboard decisions? How will transparency be balanced with privacy? How will equity considerations influence reporting? What level of documentation is expected?	Document governance principles that establish expectations for consistency, transparency, privacy protection, responsible interpretation, and continuous improvement.

2

Dashboard development lifecycle

Identify Stakeholders and Users

Activities	Considerations	Guiding Questions	Best Practices
Distinguish commissioners from end users	The people funding or requesting the dashboard and the people who will use it daily have fundamentally different needs. Building for the former and ignoring the latter produces tools that never get used.	Who will open this dashboard on a Tuesday morning? What decision are they trying to make? Have we talked to them directly, or only to their supervisors?	Use a codesign process to gather requirements from key users and stakeholders versus relying only on requirements from agency leadership.
Assess differences in your audiences' data literacy	A complex dashboard designed for policy researchers will overwhelm a school counselor with limited planning time. A tool simplified for students may not have the detailed information a district administrator needs.	What is the lowest data literacy level among your intended users? Have you observed those users interacting with data tools before?	Design dashboard views to meet the needs of users with varying levels of data literacy. Include data labels and definitions in your dashboard using plain language.
Establish a shared understanding of the target population and cohorts	Who is a "graduate?" What years does a cohort include? Do General Educational Development (GED) completers, late graduates, or students who transferred count as graduates? Different audiences might calculate metrics differently; clearly defining metrics helps build trust in the tool.	How is each rate calculated? Are alternative education completers included or excluded? How are transfers handled in graduation and enrollment calculations?	Define terms in the dashboard and how data is calculated. For example, different source data systems might calculate graduation rates differently.

3

Dashboard development lifecycle

Define and Gather Data

Activities	Considerations	Guiding Questions	Best Practices
Establish a shared data dictionary before building any displays	"Postsecondary enrollment," "completion," and "college-going rate" mean different things for different data sources and partners. Establish agreed-upon definitions so that users can trust the metrics and aren't confused by different numbers reported elsewhere.	Do all data partners agree on the definition for each metric in the dashboard? Is that definition documented, approved, and tied to a published standard (such as the Common Education Data Standards (CEDS), Integrated Postsecondary Education Data System (IPEDS), or EDFacts)?	Resolve differences in data definitions prior to integrating data from different sources. Clearly document data definitions and use of standards.
Create a formal data mapping document for every element	Every data field displayed in the dashboard has an origin, a transformation, and a display label. Without a mapping document, errors introduced in transformation are invisible and hard to trace. Mapping is especially important when dashboards draw data from multiple sources.	For each metric in the dashboard: What is the data field's name in its source system? What data transformations are applied? What is the display label? What does a null or suppressed value look like?	Document data transformation logic when converting, calculating, or manipulating data.
Document and validate record-linking methods across source systems	Matching student records across state K12, higher education, and NSC data systems is never 100 percent accurate. Match rates affect every metric calculated from linked data. When linking methods are not documented, users cannot assess the data's reliability. Systematic linking errors, such as different match rates across different demographic groups, can lead to biased data.	What data fields are used to match student records across systems? What is the expected match rate? How are unmatched records handled—are they dropped, shown separately, or flagged? Are match rates consistent across student subgroups?	Document unmatched records and gaps in data.
Document data freshness for each source and display it in the tool	Source data systems refresh their data at different times. Include release dates for all data used in dashboard metrics to prevent false temporal comparisons. Users could draw incorrect conclusions about apparent trends in data released at different times.	When and how often are data refreshed from each source? What is the expected lag time between when data is gathered and when it is available? How will the dashboard indicate the data's age to users?	Identify differences in source data timelines and ensure transparency by including data release dates and definitions in the dashboard.
Suppress small data cells in the underlying dataset, not solely in the dashboard's user interface	Data privacy regulations and best practices require suppressing data cells representing a small number of individuals—typically counts fewer than 10. If the suppression rules are applied only in the dashboard's presentation layer, they might not be applied consistently when users export data, use an application programming interface (API), or receive reports. The data must be suppressed in the underlying data layer.	What is the suppression threshold required by data sharing agreements and legal guidance? Where in the data pipeline are suppression rules applied? Does the dashboard indicate to users when data is suppressed?	Include an indicator in the dashboard when data are suppressed rather than having a value of 0.
Align option sets and code values to shared standards	Race/ethnicity categories, program codes, and credential types vary across federal reporting requirements, state collection systems, and local data systems. Displaying raw codes or inconsistently mapped labels erodes user trust and makes cross-district or cross-year comparisons unreliable.	Where do option set values in source systems differ from federal or state standards? Are race/ethnicity categories aligned to current federal guidance? How are program codes or credential categories standardized across districts?	Use human-readable labels in the dashboard instead of raw codes (such as ENRL-CD=03, displayed as “Enrolled full time”).
Refer to CEDS for standardized data element definitions and option sets	Building a dashboard that aligns data element names, definitions, and option sets to a standard like CEDS makes future federal reporting integrations, cross-state comparisons, and data system interoperability significantly less expensive. It also provides a defensible, publicly documented rationale for decisions about definitions.	For each metric in the dashboard: Does a CEDS element definition exist? Are any local definitions that diverge from CEDS documented and justified? Has the team used CEDS Align to map source system data elements to common definitions?	When using data elements that are already defined in a standard like CEDS, use the same definition in the dashboard.

4

Dashboard development lifecycle

Plan Dashboard Design

Activities	Considerations	Guiding Questions	Best Practices
Conduct structured requirements sessions with actual dashboard end users, not just stakeholders and data contributors	Supervisors and administrators describe what they think users need. Users know what they actually need. Without direct input from counselors, teachers, students, and parents during design, the tool will be built around assumptions rather than evidence.	Have we conducted structured interviews or codesign sessions with representatives from each dashboard user group? Did we document and trace requirements back to specific input from those groups? Have users seen prototypes before development begins?	Include input from direct users in their actual work context. Conduct prototype testing with users before coding begins.
Add tooltip—or hover-over—text for every metric displayed in the dashboard	Tooltip text gives users definitions and context when they encounter unfamiliar metrics without making them navigate to a separate documentation page. Keeping key information with the metric helps ensure correct interpretation.	Does every metric in the dashboard have a tooltip or info icon that shows the information counted and excluded, the data source, and the collection or release date? Can users with lower data literacy understand the language in the tooltip?	Include accessible metric definitions that use plain language.
Use plain-language labels throughout — not system field names or jargon	Dashboard users might not understand labels based on data field names or jargon. A user should be able to understand every label without needing to know the source system or technical terminology.	Has every label been reviewed by someone not a data expert? Are abbreviations spelled out on first use? Do labels describe metrics in terms that users will understand?	Use plain language to define labels.
Design the dashboard to support how users will actually use it	A dashboard that works beautifully on a developer's large monitor may be unusable on a school counselor's aging laptop, or on a parent's phone. If reports are distributed via email, they must render correctly in email clients. Understanding the real use context prevents post-launch surprises.	On what devices and browsers will users access the dashboard? Will any dashboard output be emailed or printed? What is the slowest internet connection a user might have? Have we tested the dashboard on hardware that users actually have?	Test the dashboard on multiple device platforms including desktop computers, tablets, and mobile devices.
Resist scope creep	Research on dashboard design consistently shows that adding more metrics does not help users, it paralyzes them. Each element added to the primary dashboard view makes the user less likely to act on any of the elements. Adding more data "because we have it" is the most common design failure.	For each metric on the dashboard: What specific decision does this metric support? Did a specific user say they needed this? If we removed the metric, who would be harmed, and how? Could we put the metric in a secondary or drill-down view?	Design dashboard views to show the most actionable 3–5 indicators.
Design audience-specific entry points, not one generic homepage	A student exploring career pathways, a school counselor monitoring FAFSA completion, and a district administrator comparing school-level outcomes have different starting questions. A generic homepage forces every user to navigate past irrelevant content before reaching what they need.	Does the dashboard have role-based landing views or filters? Have we mapped each audience group's user journey through the dashboard and confirmed they can reach information for their primary use case within two clicks?	Consider all potential users when designing dashboards. Avoid creating a dashboard that has a single homepage designed for one audience, such as state agency leaders, while requiring all other users to navigate through high-level aggregated data to reach the operational data they need.
Build accessible features from the start	Resources published by state agencies often must comply with Web Content Accessibility Guidelines (WCAG) 2.1 AA, which include considerations such as color-blind-safe color palettes, screen reader compatibility, and keyboard navigation. Retrofitting dashboards for accessibility is significantly more expensive than building an accessible dashboard from the start.	What are the specific accessibility requirements of our data sharing agreements or agency information technology (IT) standards? Has the dashboard tool been evaluated for WCAG compliance? Are color choices tested for color-blind accessibility?	Follow WCAG accessibility guidelines when building the dashboard. Conduct accessibility testing before launching the dashboard.

5

Dashboard development lifecycle

Build and Test Dashboard

Activities	Considerations	Guiding Questions	Best Practices
Establish a single person identifier across all data source systems	The most common data quality failure when integrating data across sources is the same student appearing under multiple IDs. Without a single, unique identifier and a solid identity-resolution strategy, joining data from multiple sources can produce duplicate counts or missed matches.	What is the primary identifier in each source system? Do all systems share a common identifier, or does matching require probabilistic linkage methods? What is the documented false-match and false-non-match rate? How are unresolved records treated in calculations?	Validate the match quality of the dashboard’s dataset across demographic groups, and document the identity-resolution strategy.
Implement role-based access controls before loading any real student data into the dashboard	A counselor should see only their school’s student-level data. A district administrator sees district-level data. A state researcher sees aggregated data. Allowing users to see data they are not authorized to see—even briefly in a test environment—violates the Family Educational Rights and Privacy Act (FERPA) and creates a data privacy incident. Access control is a design requirement.	Have we defined an access control matrix, showing the scope of data available to each user role? Has the matrix been reviewed by legal counsel or a privacy officer? Are access controls enforced in the dashboard's data layer, not just in the user interface? What audit logging is in place?	Establish access control measures that prevent users from bypassing the controls. Create audit logs to show who accesses information. Validate access levels before the dashboard goes to user acceptance testing.
Design the extract, transform, load (ETL) process to refresh repeatedly	One-time data loads are the silent killer of dashboards. The platform must be able to handle clean data transfers when new data files arrive, when source systems change their data structure, or when a district submits corrected records. An undocumented or fragile data pipeline will leave the dashboard out of date.	How will the data be refreshed? Who is responsible for triggering and monitoring each refresh? What happens when a source file is late, malformed, or missing? Is the refresh process documented?	ETL refreshes regularly and includes error handling, logging, and documentation. Refreshing data is not a manual process known only to the dashboard developer.
Validate every metric against known, accurate information before launch	Transformation errors, miscounted denominators, and duplicated counts are nearly invisible until a user notices a number that does not match what they know. Validating dashboard metrics against manually produced data counts and known cohorts helps catch these errors before they damage trust in the dashboard.	Have we selected a validation cohort and manually calculated each displayed metric for that cohort? Do the dashboard results match the manual calculation? Have we shared draft outputs with at least one domain expert who can check the numbers?	Have a domain expert manually validate dashboard data before launch to catch systematic errors before users see the data.
Give the dashboard a visible data refresh log and display refresh dates for each metric	Users need to know when metrics have different data refresh dates. A timestamp in the dashboard footer is insufficient when one metric is current as of last week but another was refreshed 18 months ago.	Can the dashboard display an as-of date at the metric or dataset level, not just a single page-level timestamp? Is the refresh log accessible to users who want to understand data currency?	When communicating data metrics, include information about data releases and updates by data source. Using a single "last updated" timestamp may give users a false impression of the currency of metrics.
Document data using CEDS element definitions	Building the dashboard and documenting its data based on CEDS creates a traceable data lineage for future reporting, cross-state comparisons, and data system integrations. Using CEDS has a low cost in the build stage with a high value later.	Is each metric in the dashboard linked to a CEDS element ID and definition? When local data definitions diverge from CEDS, are the divergence and rationale documented?	Reference published data standards in the dashboard’s documentation so future data integrators can understand the meaning of each field without reverse-engineering the system.

6

Dashboard development lifecycle

Train Users and Deploy

Activities	Considerations	Guiding Questions	Best Practices
Train users on what the data mean, not just how to click through the dashboard	Training that covers only navigation produces users who can operate the tool but misinterpret its outputs. It is dangerous for a counselor or administrator to use the tool confidently while drawing incorrect conclusions. Data interpretation training—what each metric measures, what it does not, how to avoid common misreadings—is as important as tool orientation.	Does the training curriculum include explicit instruction on common misinterpretations of each key metric? Does it explain what the data cannot tell you? Has training content been piloted and refined based on participant feedback?	Develop clear learning objectives for the training and measure training effectiveness.
Establish a clear escalation path for data questions before launch	Users who encounter numbers they don't understand or trust might stop using the tool or, worse, continue using it with unwarranted confidence. Without a named contact for data corrections, definition questions, and access issues, problems could go unreported while trust erodes silently.	Who handles data correction requests, definition questions, access provisioning and removal, technical issues, and feature requests? Is this contact information visible within the tool itself, not just in a separate email?	Provide users with a clear point of contact for both technical questions about the dashboard and questions about the data.
Run a structured pilot before statewide rollout	A pilot with real users in their actual work context can reveal usability problems, data quality issues, and training gaps that testing never finds. Piloting with a diverse group—including under-resourced settings, rural schools, and low-data-literacy users—ensures that the tool works for its most challenging audiences.	Does the pilot include users from diverse contexts (for example, urban and rural locations, high-capacity and under-resourced districts)? Is there a structured way for users to provide feedback? Is a process defined for incorporating pilot feedback into the dashboard before its broader release? What criteria will determine whether the dashboard moves from the pilot to a statewide launch?	Include participants in the pilot that represent a range of user perspectives and abilities. Systematically review user feedback and make changes if needed before full rollout.
Produce role-specific, plain-language user guides—not just technical documentation	Technical data dictionaries serve developers and data analysts. School counselors, parents, and students need a one-page "what this number means and what to do about it" guide for each major metric, written in their language. These documents can be the difference between whether a tool is used or ignored.	Is there a separate, non-technical user guide for each primary audience type? Was the guide written with input from people in that audience? Does it include examples of how to interpret and act on key metrics?	Create a user-friendly dashboard guide that is written in plain language. Gather feedback on the dashboard guide from actual users.
Measure adoption and usage, not just training completion	Training completion counts and output metrics (such as dashboards deployed and users trained) are necessary for grant reporting but do not show whether the tool is being used or if it is supporting better decisions. Dashboard use is the feedback loop that justifies continued investment.	Is the dashboard equipped for usage analytics (such as page views, filter usage, export events)? Are there outcome metrics that connect tool usage to student-level actions (such as FAFSA completion follow-up rates)? How will usage data inform the next iteration of the dashboard?	Establish dashboard success metrics based on desired outcomes. Outcomes may include metrics such as number of users, time spent performing certain activities using the dashboard, or longer term outcomes such as changes in behavior.

7

Dashboard development lifecycle

Monitor and Maintain

Activities	Considerations	Guiding Questions	Best Practices
Build a sustainability plan before the grant period ends	Most dashboards built on grant funding go dark within 2 years because no one planned for post-grant hosting costs, staff time to refresh data, or ongoing user support. A sustainability plan must exist before the grant ends, not after.	What agency budget line will cover hosting and maintenance after the grant? Who is responsible for the annual data refresh and what does that work entail? Is an owner named for the tool once the grant period closes? What is the minimum viable maintenance scope?	Build scalability and sustainability into the dashboard plan from the beginning, including both staff and budget requirements.
Establish and follow a data governance structure	Who approves a change to a metric definition? What happens when a source system changes its schema? Who adjudicates a dispute between two partner agencies about how a number should be calculated? Without a governance structure, these questions paralyze progress. With one, they are routine.	Is there a named cross-agency data governance body with defined decision rights? What is the process for proposing and approving a change to a metric definition or data source? How are decisions documented and communicated to users?	Create a data governance plan that includes defined decision rights, a process for adjudicating definition disputes, and change control documentation.
Track versions of metric definitions and document every change with a visible change log	When a definition changes—such as when inclusion criteria shift, a new denominator is adopted, or a data source is updated—users will see a trend break and lose confidence. A visible, dated change log explaining what changed and why is the only mechanism for maintaining trust across definition changes.	Is there a version history for each metric definition? When a definition changes, are users notified within the tool? Does the change log explain the reason for the change and its impact on trend comparisons?	The dashboard should note changes to metric definitions that explain why year-over-year trends break.
Document opportunities to align data across states while building the dashboard, even if that is not a near-term plan	Aligning to common element definitions like CEDS, shared NSC linkage methodologies, and standard disaggregation categories during the initial build reduces the cost of cross-state comparisons and national benchmarking later. This is a low-cost investment at build time with high future value.	Are our metric definitions aligned to CEDS and federal reporting standards that other states use? Are our race/ethnicity disaggregation categories consistent with current federal guidance? Could another state replicate our metric logic using only public documentation?	Document state-specific metric definitions and relationships to published standards that might make cross-state comparisons easier.