Building Consistency: A New Component for the
Amex Design System
Amex Design System
ROLE: proDUCT Design lead
PROJECT TEAM: COMMERCIAL PRODUCT DESIGN TEAM + DLS DESIGN and DEV TEAM
CLIENT: AMERICAN EXPRESS
TIMELINE: 4 months (conducted as a side project in addition to main tracks of work)
TIMELINE: 4 months (conducted as a side project in addition to main tracks of work)
THE CHALLENGE
To create and contribute a file upload component for Amex’s Design Language System (DLS) that is scalable and applicable to multiple use cases across the Amex ecosystem, in order to reduce inefficiencies and increase consistency of experience for users.
THE OUTCOME
A file upload component and design pattern that’s been digested into Amex’s DLS and now serves as the “source of truth” and consistent component and pattern for file upload designs across the enterprise. BACKGROUND
When we began, Amex’s Design Language System did not include a design for a file upload component. Consequently, designers and tech teams across the AmEx ecosystem were spending time creating components that were similar in function but inconsistent in terms of design. This resulted in inefficiencies and inconsistent user experiences across the Amex digital ecosystem.
The Amex DLS has a dedicated team for managing and expanding the system, but they are a small team facing a large backlog of enterprise asks and needs. When several designers from the Commercial UX team found ourselves working on projects that all needed file upload designs (and we found ourselves working in accidental silo’s, and designing inconsistent experiences) we volunteered our time to create and contribute a file upload component and design pattern, with the blessing of the DLS team. As a result, this project emerged as a side gig and passion project for myself and 4 other design teammates.
RESEARCH + DISCOVERY
Enterprise File Upload Audit
We began by gathering as many different instances and use cases of file uploads that currently existed across all Amex digital experiences. We reached out to designers across the enterprise, asking them to share any current state or planned future-state file upload journeys. As word got around, it was amazing to see how many design teams reached out to us! This validated any remaining questions we may have had regarding a need for a consistent component and pattern. We documented each team’s contribution in Confluence and also did a scan on our own to capture additional instances that weren’t surfaced to us by teams.External Pattern Audit
We also looked for external document upload patterns to reference, reviewing together and discussing the strengths, weaknesses and potential applications of each. We looked at Dropbox, Google, Turbo Tax, Jira, and a slew of other companies, especially seeking out those who helped users manage complex uploads involving file organization and designation.
DefiniTION + IDEATION
Moving into problem-framing, we outlined the user goals we’d identified during discovery. We looked at how they overlapped with the business goals (which we’d identified through our strategy audit and stakeholder interviews).
Task Flow Mapping
Informed by the use cases we’d collected across the enterprise, we workshopped a “note and map” exercise where we each noted the distinct steps for users in the file upload process and posted them up, then voted on the steps we felt best described the process.
Emerging from this exercise, we aligned on 3 variations of the file upload task flow journey: Single File Upload, Multi-File Upload, and Batch Upload.
Coming out of this exercise, we were able to better anticipate which use cases might best employ a “freestyle” drag and drop/batch upload pattern and which ones would benefit from a more step-by-step approach, with pre-defined and pre-formatted categories provided.
Sketching + Ideation
With these task flows and use cases in mind, we moved into ideation and sketching. We started out with a Crazy 8’s exercise to generate some initial ideas quickly, then selected our favorite ideas and developed them further. We then presented to the group and dot-voted on aspects of each that we felt were strongest and most promising.
From here, we defined the requirements and outlined the task flows in more detail. Finally, we moved into digital sketching and started exploring the best way to reconcile and integrate our ideas with existing DLS styles and components.
ProTOTYPING + TESTING
As we worked on the project, we kept in close touch with design teams who were currently working on experiences with file upload needs. We knew they’d be conducting usability testing as they worked towards delivery of their own projects, so we coordinated with them to include our file upload component and design patterns. In this way, we were able to test and gather user feedback, despite lacking a dedicated budget.
Two projects in particular were quite useful in helping us gain insight into how users organize their thinking and approach to file uploads:
1) A Business Financing Application:
Uploading financial statements for different fiscal years
2) A Credit Card Application:
Uploading personal ID documents and designating which types have been uploaded
Key questions we brought into both testing opportunities included:
• How familiar and comfortable are users with drag and drop uploading?
• When asked to upload multiple documents, do users prefer to upload in batch form and then organize the files as needed, or do they prefer to upload to separate sections in a phased approach?
Findings + Recommendations
Testing provided feedback both specific to the contexts of each use case and across both experiences. Overall, some key takeaways were that:
• Drag and drop was useful and familiar to all participants
• Users felt reassured by the progress bar and green check mark to indicate that their files were uploading successfully
• Some users want the option to preview a file after it’s uploaded
• When asked to upload multiple types of files, users preferred having the categories clearly and separately defined, with separate opportunities to upload to each (vs. uploading in bulk and categorizing afterwards). They frequently overlooked an option to categorize when it was provided after uploading and before submitting.
• Participants often need extra time to collect information and documents such as bank statements, Tax ID and business revenue files, proof of identity, etc.
ITERATION + DELIVERY
Using the insights gained from testing, we iterated on the file upload design component and patterns, designing for error states and going back and forth with the DLS team as we worked to make sure the UI was consistent with that of the overall system.
As we defined simple and complex design pattern recommendations, we moved away from asking users to upload in bulk and categorize afterwards. We embraced the version preferred by users in testing that presented distinct upload categories, with separate opportunities to upload to each.
We also added recommendations to provide a clear and detailed summary of what users will need up front, and a recommendation to provide a clear and visible “Save and Return Later” option for users.
.DLS Coordination + Handoff
We’d stayed in conversation with our DLS teammates throughout the process to get their input, guidance and thought partnership along the way. At last, we handed over our spec’d files to their team for ingestion into the system. For all of the specific use cases we explored, in the end we delivered a very minimal, atomic-design informed component and pattern resource that we were confident could be used by designers across the enterprise in the various contexts needed.
The file upload component and design pattern now reside within the DLS component Sketch Library and the Design Pattern Reference file, and are included in documentation on Amex’s DLS site. Amex designers now reference and employ it when building experiences that include the need for users to upload one more more files.
A remaining complexity uncovered during the project is that it’s difficult to ingest the component into the DLS as a React Component since different Amex products have very different backend arrangements. In contrast to some of the components that development teams can employ as “plug and play” from the DLS kit, the file upload component still requires customization. That said, it can still feel seamless from users’ experiences on the front end, and as teams begin to incorporate and build the new design pattern into their own realms, the DLS team is documenting use cases and connecting teams so that they can leverage one anothers’ work and customize as needed.
Final Thoughts + Takeaways
Contributing a single component to an enterprise design system is in itself a significant lift, requiring coordination across the enterprise. It’s a great exercise in thinking systematically and shifting between considerations of atomic design and specific use cases and considerations. This was one of the early projects I worked on during my tenure at Amex, and it was a great way to better understand the different context and needs of designers and users across Amex (consumer and commercial, internal and customer facing).
Since this project, I’ve had the opportunity to lead teams in developing, employing and maintaining design kits that serve as product-specific design pattern libraries within Amex– remaining consistent with Amex’s DLS while building out further design patterns that serve the needs of the platforms and products more specifically. The key takeaway for me is always that these systems are not static– they’re never “final” and are in fact almost living organisms, with a need to both reference them and update them constantly according to the evolving needs of business, user, and tech.