My day-to-day work can be broken up into three major pieces:
- System architecture work is the big-picture thinking that outlines major initiatives to determine the structure and function of our application.
- Creating and maintaining design systems supports the rapid development of new features, and ensures consistency and good design practices across the application, including use of color and typography to support app visual hierarchy and chart interactions.
- Feature design and development describes the individual details of each new feature that we build, and generates a full engineering specification for new features for development, including all style definitions and interactions for charts.
The majority of my system architecture work focuses on determining which data is acceptable for different chart types, and automating the chart configuration and selection process, as well as consulting with engineering about how users can input information to configure our charts in the application design mode. We work with several different metadata structures (measures, dimensions, time periods, etc.), each of which can be displayed differently in different charts. I create the chart input assignments to specify which data can be shown where, and how much data (10 series, 100 series?) can be shown in a given chart. I also developed a weighted-sum formula for determining which chart is the best fit for a particular user task, based on a series of user inputs.
My architecture work also involves specification of system-wide features, such as an application-level persistence paradigm that determines when the application remembers a user setting, and when it forgets. This includes user selections such as theme, data filter, table sort, chart interactions, etc., and specifies whether they are kept, reset, or overwritten by other user actions, such as viewing the page on a different device, in a different web browser session, navigating to a different page, or interacting with a different chart.
Our application relies on a series of UX, UI, and data vis design systems, which all have to function together to create a seamless whole. I collaborated with our UI designer to create a color and typography system for data visualization that works within the broader UI style of the application. I apply and maintain this system for all chart types and other data-visualization-related features of the app, as well as re-aligning with the UI system for different themes and UI color updates.
I also collaborate closely with our UX designer to ensure that chart interactions are consistent with other UX paradigms within the application, and that they support the user in accomplishing specific analytical tasks. I design interactions for each chart in our library, and deploy the data visualization style system to create a visual hierarchy that communicates the results of the interaction.
I have written more about designing color systems for data vis here, and have recently been exploring several aspects of creating design systems for charts on the blog, under the Form to Data tag. The video below shows our data vis style system in action, supporting interactions in a stacked bar chart.
The system architecture decisions and data vis design system pieces come together in detailed specifications for every feature in the application. The architectural choices help to define what the features are, and then I work with the business team to figure out how to stage them and write them into bite-size tickets to feed our agile sprints. Each ticket contains a set of detailed criteria that explain exactly what the feature needs to contain, in sometimes-excruciating detail. (The image below shows a small subset of the specifications for how axis labels are drawn in a chart.) These detailed specifications make it easier for engineers to estimate the effort needed to develop a feature, and ensure that they have clear criteria to develop against, and that QA can check after development is complete.