When Proteus started its design journey…
the design team was small and the focus of the team was to craft solutions that would help patients through their treatment journeys. Proteus started within the treatment area of CMD (Cardio Muscular Diseases). The team shaped mobile and tablet based solutions for patients (iOS and Android) and web based solutions for Health Care Professionals (HCPs). Design specifications were created using Sketch and documented using confluence.
As proteus grew…
it expanded the therapeutic areas to Oncology and Mental Health. This meant that the design team had to support multiple customized therapeutic areas. The design team evolved into the UX team with multiple designers, researchers, technologists and human factors. There were more stakeholders and users for design specifications and documentations. Confluence was not build for design specifications and the team migrated to Zeplin. However, with the addition of more team members the design documentation process became more and more complex and difficult to maintain and manage.
I was tasked with…
understanding design documentation related needs at Proteus and to come up with a scalable and flexible documentation process that would work for all the stakeholders.
My Role
Project Driver
Year
2019
Problem
As the teams scale, the design documentation and delivery process that used to work is no longer effective. We need to improve how we author, review, manage and hand off design specs across Proteus cross functional teams. Deploy a more efficient and effective way to access, document and communicate experience design intent across our execution teams
The existing design process was spread across multiple tools. The team used Sketch for design, Plant for versioning, Confluence and Zeplin for spec documentation, Lucid chart for flow charts , Confluence for requirement documentation, Box for storage and InVision for prototyping needs. The use of multiple tools and the use of different platforms to conceptualize and deliver designs lead to a non efficient documentation process.
Thus since assets, resources and work activities happen in multiple tools, places and repositories it was hard to bring together the full picture of work related to any particular capability. Specific elements helpful to deign, test and build more effectively are absent from design docs: testable prototypes, motion samples, responsive behaviors, style and component libraries, etc. The disconnected publishing of specs to confluence and Zeplin, leads to errors, spec inaccuracies, out of date content – all while requiring extra work to create and maintain. The specs did not provide easy access to detailed layout, style, interaction, motion, animation, typography, and function.
Key Players
Primary Users : Product designers are the primary authors and frontline managers of the design spec ensuring they are current and communicating updates to the broader build teams.
Secondary Users : Other than the product designers, a number of teams and people access and regularly refer documentations. These include Design Technologists, User Researchers, UX Architects, Human Factors Engineers, Developers, QA, Product Managers etc.
Tertiary Users : Design documentations are also referred by Scrum Masters, Customer Support, ETQ professionals to complete their tasks.
The spec document should always reflect the most recent changes, act as a single source of truth while retaining the evolution process. The process should not force designers to do extra work to update documents but should be capable of versioning changes and updating all related documentations to ensure everything is in sync. The tools and process should support continuous engagement of all users.
Tools and process selected should allow easy and effective collaboration, not only between designers but all the users. This would mean establishment of easy to follow process that could be replicated by novice to expert users, a common set of components that could be shared, updated and reused, an effective method to update components and documents when changes are made by peers.
Supporting multiple users who collaborate with each other would also mean creation of clear and well segmented documentation. Segment the spec document into smaller meaningful parts rather than creating one big document to ensure easy access.
A well crafted document reduces the questions that a reader would have. It provides details with assets, flows, and component behaviors thereby telling the complete story behind the designs. All related details regarding a certain feature should reside together as part of a well segmented and clearly articulated document.
Approach
Find the right tool
The current Sketch-oriented workflow relies on tools like Zeplin and Confluence to handle handoffs, Plant to cover version control, and Invision to design prototypes. Managing multiple tools to complete a single process meant that documents would get out of sync from time to time. Zeplin and Confluence might not reflect the most recent assets, designers might forget to update all the related features, two designers might be on different versions of a single sketch file etc.
Thus the first step was to find the right tool that would reduce the work load on designers. I decided on Figma which was a powerful and evolving tool that supported designing, handoff and prototyping in a single space.
AUDIT AND CATEGORIZE
Back in the days when Proteus Design Team was small and when the company concentrated just on Cardio Muscular Diseases, designers had to only maintain a limited set of assets. However with the company’s expansion to multiple therapeutic areas and feature additions, the number of assets grew and the master Sketch file became larger and larger.
When the file was segmented, design assets also got segmented and individual designers maintained assets related to the pieces they worked on. Not having a single core library meant that I had to audit all the existing design elements from typography, color, icons to templates and pages.
An audit was conducted to collect all the components. These were then categorized into specific buckets. Rogue components, type or colors found were marked and discarded. Once all design components were categorized, I conducted an audit of all spec documentations, flows and prototypes we currently held and maintained. This helped to estimate the amount of work that had to be done to migrate all these to Figma.
STRUCTURE AND CREATE
The next step was to create a structure to remodel the component library. This not only included organization of components into a structured library but also to come up with a structure to build scalable interconnected components that could be used and reused by the team.
At Proteus, we had our core product “Proteus Discover” and customized variations of the same for different therapeutic areas(TA) like Oncology and Mental Health. Thus we had to maintain different customized applications depending on the therapeutic area. This meant that while there were a core set of components that were used across different apps, there were also custom components used specifically for a TA. This led to the formation of a core/parent component library and child libraries specific to TAs. Themes were separated from component libraries to ensure that any component could be skinned based on a selected theme.
Atomic Design
The Atomic Design advocates breaking down design into smaller particles for creating and maintaining robust design systems, allowing you to roll out higher quality, more consistent UIs is a methodology composed of five distinct stages working together to create interface design systems in a more and hierarchical manner. These different stages are:
Atoms
Molecules
Organisms
Templates
Pages
Component Libraries
I chose Brad Frost’s Atomic Design principles to craft and build the component libraries. On top of following the atomic design principle we also created our own set of guidelines to ensure we created strong reusable components.
When components have variations, they should be created from a single master component that could be manipulated easily.
Utilize grids and layouts to create robust and scalable components.
Make finding components easy: Group components together to ensure they are organized in a meaningful manner in the team library. Grouping creates a layered team library instead of a library with a lot of components to go through.
Use universal names or accepted names for components to make them easily searchable.
Add a concise and clear component description to all components so that users can get the use of the component before using them.
The Core Asset Library is created using Master Components. This component does not get published to the team libraries but instances of it just get used in creating other components. This helps in easier globalized changes. These nested components are published into the team libraries. Constraints and layout grids are often attached to the master component to ensure predictable resizing and cannot be overridden.
COMPONENT DOCUMENTATION
Once the component library was created, my next step was to ensure that the whole component library was well documented. A well documented component library would speed up the work of designers and would also act as a guidebook for any new designer joining the team.
I explored and studied many design systems and library documentations for this process. I landed on a format inspired by Google’s Material Design documentation. Each component set had a document that would provide the following details
Component Summary
Usage and Industry Best Practices
Classifications
Anatomy
Details on component states and use of colors
Component Type Details
Example and guidelines
Project and File Structuring
Structuring and organizing just the design components would not solve our issues. We need a way to organize these components into different files in a way that is meaningful and clear for a more productive handling, not just for the design team, but for all the other key players.
With Figma, we created multiple teams, each team holding specific type of documentations but sharing a similar organizational structure to ensure uniformity.
As we organized projects and files within the Team, the goal was that the files are easy to access, files can be scanned quickly for details and the current status. Detailed organizational features are currently not available in Figma and hence we had to create our own methods for these purposes.
In order to ensure that spec documentation remained clean, we separated explorations and iterations from the final spec document. One of the main reasons for this was that a lot of our features have two faces : the patient side and the provider(or health care professional) side. In the incubatory phases we design the experience end to end holistically and hence had to originate from a single space. As the designs progressed and became more and more distinctive they were separated into its own medium/persona as Patient(Mobile) and Provider(Web). Specs were placed in these individual teams since there were hardly any co-dependency and cross reference that happened at this stage.
Impact
The project resulted in a well documented shared team library that was now used by the entire design team. Designers could now spend their time in designing experiences and exploring concepts. Designers now did not have to worry about maintaining components or making sure every component was in sync. The process we came up with assigned gate keepers for component libraries who managed the library periodically.
Opening up the design space to extended teams like Product Mangement, Software Engineering and QA creating a collaborative space that helped in shaping a more meaningful and thorough design experiences. All parties involved were now involved throughout the evolution of a project which created a very strong feedback loop that lead to reduced design discrepancies and bugs. Designs were now made more accessible to all team members.
The new documentation process made updating designs easier which in turn made sure every thing was in sync. This highly reduced the time spend by designers, PMs, Engineers , QA, Customer support etc in finding answers and specifications that were up to date.
Designs were now scalable and easier to manipulate. Detailed documentation ensured that designers followed specific patterns and used the correct components in the correct instances.
The time spend on documentation by designers decreased since pixel perfection was not required anymore. Layouts, grinds and use of team library components ensure uniform designs through out the apps.
