Build a foundation of enjoyable consistency
2024
Beginning with my time working on the Kuali Student project, I have spent over a decade serving the primary caretaker of a deep library of design patterns used by our product and implementation teams to communicate and deploy consistency in our feature development. This is a critical investment of design and engineering resource that allows for UX to be baked into our interactions and helps increase our team cadence.
With Acadis, this materializes as a series of Axure libraries that our designers use to drag-and-drop interactive widgets onto pre-constructed pages to create high-fidelity mockups. These mockups demonstrate both the appearance and the interactivity of the proposed feature changes to our enterprise application. Many of these widgets reflect design patterns in the code, as well, which allows systems engineers to quickly recognize and configure interactions that have predictable behavior.
Building this flexible foundation has been an important part of our design strategy since my arrival, reducing the “one-off” solutions offered by individual designers and engineers and instead creating an interaction language everyone can understand. The patterns used in our applications are designed collaboratively, treating each widget our adjustment to existing behavior as feature development. This means thorough internal critique and technical input to arrive at the best decision.
Our design systems are works in progress, allowing for new information or use cases to let our interactions evolve. This work predates Google’s Material Design, which is in use by some other Vector Solutions products. On the horizon is a task or reconciling our various design systems into one that can serve the needs of all products and foster continuity between our applications.
Our Acadis design system includes:
Status
Twelve status types are defined by name and color combinations to cover the variety of states in which our data records may reside. These standards are then used to build custom sets for each kind of record, as well as propagate into our visualization information graphics. Statuses can take several forms: pips (for state changes), pills (for process changes and life cycles), and razors (prominent status indicator built into the header).
Alerts
When we want to augment or interrupt a task with relevant information, we have several patterns governing placement of that message and its appearance. Four color and glyph combinations represent message types of Information (blue), Warning (gold), Error (red), and Success (green). Alerts are also placed in containers and positions most relevant to the context of the message, including field-level validation, page footers near the submit action, temporary growls, and persistent panels at the top of the page.
ActionStacks
The actions we offer people interacting with our applications have been standardized to allow for multiple forms and styling. Dubbed “ActionStack” internally, these can be single buttons or links, combinations buttons with a dropdown menu, or toggle buttons to change states. There are stylings to differentiate a primary action from secondary actions and navigation, and to provide visual indications of the interaction before the action is taken.
Modals
For actions that are contextual to a page but require additional data collection or secondary actions, we have a modal container that displays on top of the current page. These have their own versions of form widgets with layouts specifically for modals to allow for rapid prototyping.
Input Fields
Our data entry uses left-side labels for easy scanning and placeholder text to provide context or prompts about what to enter or select. In smaller viewports, these become top-side labels to better fit on mobile devices. Each Axure widget has easy options to hide the indicator for required fields and to show a help callout that can contain more detailed information about the purpose and use of the data.
Tables
These are complex widgets that range in the interactions and information thy support, from a simple table without actions to our selection tables, which have an initial column of checkboxes. Rows are highlighted in different ways to reinforce where the focus is and allow for horizontal scanning. Our tables are also printable in two layouts and customizable, allowing each viewer to determine which information to prioritize.
Iconography
We expand and maintain a list of custom glyphs built in Illustrator and formatted as a font through IcoMoon. While a core set of these glyphs are common to other font sets, many are specifically designed to provide a visual language for Acadis.
Annotation
Since our mockups are primarily used to communicate with the feature implementation teams, we also have a visual language around annotation of the mockups. These are intentionally styled with a different font and color scheme, so it is less likely to be confused with the high-fidelity appearance of the feature.
Text Patterns
Production text is an in important opportunity to help someone using our application to understand what will happen before taking action and the outcomes of those actions. We have several containers for visible text (e.g., section captions) that follow some consistent structures that are maintained in some documentation. While not always interactive, production text is a critical part of understanding and way finding through user interfaces.
