Information Architecture

Root + STEM: Data Design


Prior to developing Root + STEM, only a PDF documented the STEM programs that were available in the state of Hawai’i. Our task was to turn the static resource into a living web app that had the potential to be expanded through community contributions.

In addition to our primary ojective, I made it a personal goal to architect the data to be an example of an optimized content infrastructure for both developers and content managers.

Our Team

Kelli Borgonia, Project Lead, UI Designer
Jon Borgonia, Senior Software Architect
Te Vallee, Full-Stack Developer

My Role

I designed the data infrastructure and worked with the developer to ensure that it was implemented to spec. I designed all layouts and hand-coded all CSS.

User Groups

People would typically interact with the website in one of four ways:

  • Community Contributors would submit STEM programs to the database.
  • Students and Teachers would search for STEM programs.
  • Website Administrators would approve and publish or request changes to submitted STEM programs.
  • Casual Users (potentially policy makers and program funders) would search for insights and information.
Root + STEM user groups

Root + STEM user groups

Data & Infrastructure

After examining the team’s original database and reading the initial PDF report on STEM programs, I worked with the research team to define the properties that we would want to start collecting once users had the ability to contribute STEM programs to the web app.

Part of the spreadsheet during the planning period.

A section of the spreadsheet during planning.

Since the web application would house a combination of informational and community-contributed content, I planned to separate all editable content from the web app infrastructure.

Whenever possible, I design infrastructures to be sustainable. I have witnessed so many projects where content change requests end up wasting 80% of a developer's time. To mitigate this inefficieny, I always work with a CMS to ensure that content can be updated independently by content creators and managers, so that developer resources can be reserved for functional code changes.

My sketch of the general content management infrastructure.

My rough sketch of the content management infrastructure.

I discussed my plan with Jon Borgonia and he translated my sketch to a real infrastructure map:

My sketch of the general content management infrastructure.

Developer infrastructure diagram.


The Programs section pulled all STEM programs data from Firebase and rendered it as a searchable, filterable list. I studied several similar websites and noticed that they all had overly complex filtering and search capabilities. Since this was the site’s first iteration and there were less than 200 initial programs, I limited the filters to properties that would return the most general results: Program Type, Target Age Group, Industry, and Region.

STEM Programs available in Hawai'i

STEM Programs available in Hawai'i


I structured the Contributors interface to be simple and straightforward. Users could sign up, add information about their organization, then fill out a 3-step form to submit a STEM Program. Once submitted, the program was set to a “Pending” status to be reviewed by a site administrator.

STEM Program approval flow.

STEM Program approval flow.

STEM Programs available in Hawai'i

The STEM Contributor Portal was built to be mobile responsive. Mobile screens shown above.

Airship Admin

Despite its simple appearance, the Contributors UI was robust under the hood. All form questions in the program submission flow mapped to data fields in Airship CMS. Utilizing a CMS gave me the ability to update the text for the rest of the website as well as the fields and options for all the forms and search functionailty while the developer continued to work on critical web application infrastructure.

Here is an example of form field data and a list of options that can be configured by a technical manager independently from the development cycle:

All form fields and options could be edited independently by the content team while the developer worked on core logic.

All form fields and options could be edited independently by the content team while the developer worked on core logic.

Programs Admin

The Programs Admin interface allowed admins to log in and review pending STEM programs. After review, admins could then approve and publish, or reject a program with notes for revision.

A very simple admin approval UI for programs.

A very simple admin approval UI for programs.

These interfaces were kept intentionally simple. Instead of building a single large app that could do everything, we intentionally built a minimal interface that could allow admins to perform a single function—approve or reject STEM programs.


The Map was a representation of all Hawai’i STEM Programs plotted on a roadmap that extended from Pre-K to adulthood. Building it was a collaborative effort between Te Vallee and I. Te translated my very detailed notes on data structure into logic for filters, dynamic captions, sequentially loaded data, and loading animations. I built the CSS Grid structure, custom CSS charts, and designed custom graphics.

A very simple admin approval UI for programs

A small snippet of the spec I wrote for the map logic.

Each STEM Program in the database was visualized on the map with a shape and color that correlated to specific criteria. In a separate case study (coming soon), I explain the specifics of this data visualization.

Full length map of Hawai'i STEM programs.

Full length map of Hawai'i STEM programs.

View the live map here.

Dynamic Options

I spent a lot of time planning how to display and mange categorical information that contained dynamic options. For example, industry categories are broken down into categories and sub-categories.

I set up categories and sub-categories in the CMS so they could be managed and edited as needed without the content changes affecting the development timeline. Jon suggested using a "/" notation to indicate drill-down subcategories.

Content management for STEM industry categories and subcategories.

Content management for STEM industry categories and subcategories.

In the Contributors form, industry categories display as a multiselect field. All options entered in the CMS are pulled into the form as options in the multiselect.

Options from the CMS populated the options in the Contributors form.

Options from the CMS populated the options in the Contributors form.

In the Programs list, the same industry categories list is pulled in from the API.

Selected options added to a list.

Filter options in the Programs list.

In the Map, we filtered out any categories and subcategories that would return a search result of 0.

Empty categories and subcategories are removed from the map filters.

Empty categories and subcategories are removed from the map filters.

The system was also designed to be extendible, so any type of categorical data could be easily organized. The same system logic was automatically implemented for the STEM program properties for "Target Age Group" and "Region."

Why does this matter?

It may all be behind the scenes, though I enjoy designing systems that are maintainable for both managers and developers. As a product owner myself, I don't like to spend maintenance resources paying developers to implement text changes. Similarly, developers don't want to be doing the equivalent of data entry. I believe that any infrastructure that allows content to be decoupled from code streamlines processes, keeps things sustainable, and most importantly, ensures that everyone on a project team is utilized in the areas of their expertise.

A Typical Project Plan

Timeline without a CMS

Timeline without a CMS

With a typical web app development, initial programming is fast, but there is a long cycle of content revisions prior to launch and incremental revisions post-launch. This plan is perfectly fine, and possibly preferable, for a product that is likely to evolve rapidly, post-launch.

This Project Plan

Timeline without a CMS

Timeline with a CMS

When utilizing a CMS in development, initial programming takes longer and may be more costly, but resources are used more efficiently. 100% of developer time is used for developing features. Content is decoupled from code. Maintenance costs are reduced. This structure makes sense for a product that doesn't have plans to undergo systemic changes in the short to medium term (1 - 2 years), yet needs the flexibility to be extend and configure data within the constraints of the system architecture.

Comparison of developer resources.

When using a CMS, developer resources can be 100% utilized to build features instead of content changes.