SLI (also known as the Shared Learning Collaborative, and later as InBloom) was a foundation-funded initiative to built an infrastructure that states and school districts could use to securely share student data with technology vendors. Wireless Generation was the prime contractor.
The goal was to facilitate the development of a more robust marketplace for K-12 educational systems—sort of an “app store” for school districts. For example, in an SLI-enabled environment, vendors would not have had to separately integrate with many different SIS (Student Information Systems) platforms in order to access school enrollment data. More transformationally, a vendor working on personalized learning products could have potentially drawn upon student data that might have originated in another vendor’s system.
My role on SLI evolved along with the project itself.
I helped both the client and the rest of the technical team to understand many issues related to educational data. SLI adopted a pre-existing third-party educational data model known as Ed-Fi, and I had the central role in vetting that model, working with its owners to modify it in various respects, and then helping the SLI technical team to understand it. At right I show one example of that analytic work.
As an infrastructure / middleware / API project, SLI did not involve a lot of conventional UX design, but one aspect with more UX work was the development of a set of data dashboards for educators and school administrators. The navigational diagram below shows the different types of dashboards that were available at different levels of the system hierarchy, along with default drill-down paths. For instance, the leftmost column shows that if the current selection is a district, the available dashboards would all be lists of schools. Drilling down on an elementary school would navigate to a list of grades for that school, whereas drilling down on a middle or high school would navigate to a list of courses. Other types of dashboards available at the school level are lists of grades and teachers, but these are not on the default drilldown path.
The following table provided a matrix of types of dashboard views that could potentially be created at different levels of the system hierarchy, and prioritized those that offered the most value. 
The last example of documentation I prepared for this project accompanied the previous diagram, and provided a concrete example of each supported and unsupported use case shown in the earlier table.
