Cross Street Design System
The foundation of a design system for Cross Street's iOS, Android, and web platforms.
I led the process to establish a design system and incorporated feedback from engineers on my team.
PROBLEM & GOAL
When Cross Street started as a mobile app project, the team decided that we were going to build iOS and Android in tandem due to our user demographic being about 60/40 iOS to Android. We also knew that our core users would be communicating and interacting with clients and other agents who were not official Cross Street users, yet would still need to respond or provide input through a web interface. With multiple platforms to design for and with a few general design and brand principles, I started to lay the groundwork for what would be the building blocks for a design system for Cross Street's iOS, Android, and web platforms.
PROJECT CONSTRAINTS & TRADEOFFS
As a very early stage startup trying to launch our MVP, I had to be mindful of how much time I allocated towards building and documenting the design system for a unified experience versus designing the actual product. We didn't have enough lead time in the design phase to have a finished design system or component library before or after the product design process.
For the most part, I had to organize and update the components in the design system while in the development phase of the app as that was the only time I had.
Knowing that a design system included: full documentation of standards, use case examples, explanation of philosophy and rationale of design decisions, I had to strategically pick my battles and focused on building a very clear component library and style guide, while communicating the rationale through our weekly sprint planning calls or whenever it came up. The priority was to ship out a working MVP and so starting with a component library and then creating the rest of the documentation for the system would be after validating the MVP.
During this time 'design systems' were on the rise and being published by big tech companies like Google, Apple, Facebook, Dropbox, Airbnb, Spotify, Uber, etc. I knew that I wouldn't be able to be as thorough as these companies because they have dedicated teams to just work on the design system, but it was important to move in this direction as it would pay off over time and I wanted to start the project off on the 'right foot'. There were many products in the market that were usable, but there was a huge discrepancy and inconsistency between the mobile and or web platforms.
After going through each of their documentation and rationale, I decided that Airbnb and Spotify had solutions that I could see as fitting to our user persona. As I conducted an analysis on each screen of their UI for iOS and Android, each major screen had one CTA and purpose as well as list cells that were flexible to be reusable in different screens, contexts, and with more or less details. What I liked most about both of their design systems were that they didn't have a visual aesthetic that was 'very' iOS or Android. It was functional, minimal, and delightful.
I also read through both Apple's Human Interface Guidelines and Google's Material Design Guidelines so that I would preserve iOS and Android specific interactions and patterns. I made sure that the flow of screens of where the transition comes in as well as exiting followed iOS' swipe from left and Android back button vs 'up' a page patterns. Throughout the app I utilized a Floating Action Button (FAB) on various core screens to indicate core actions, but didn't want to take away from the existing data and details.
I started the project in Sketch, but since this was before Linked Libraries in Sketch was released, I had made a switch over to Figma as they had a Master Component Library that can be referenced across multiple files. My Sketch files were getting too bloated and laggy.
Figma was also a good decision to move to since I was constantly re-exporting the newest updates to components through Zeplin, however there's always a few artboards that just got overlooked and it was more time wasted with developers going back and forth. Everything in Figma was up to date and live for developers to peek into, but also my Product Manager and founders who always wanted to see the latest design changes.
LEARNINGS & TAKEAWAYS
Producing a systematic approach for reusable components throughout the Cross Street UI that serviced iOS, Android, and web was overall successful to our team. Though engineers worked on different platforms, we were able to have one point of reference to discuss how each component should look, feel, and interact within layouts of screens. Furthermore, our process of me sharing the updated designs early to get feedback from them before it was put into a user story was significantly effective to catch any oversights that would break continuity or best practices.
Centralizing our focus and resources on building a clear component library for our MVP was strategically wise and if the project had more time post-MVP I would then allocate my workload to detail out the design system with examples and explanations of do's, don'ts and rationale.