All names and trademarks are intellectual property of Signifyd. All information pertaining to this study are my own and do not reflect the views of Signifyd.
The Challenge
ENABLING CUSTOMERS TO BE SELF-SUFFICIENT
In my second quarter with Signifyd, I became the lead designer for the the APIs and Developer Experience (APEX) team. I became involved with the project following the initial wireframe concept for Developer Tools, the web management application for API integrations, and the original design for the Developer Center, a microsite for integration resources.
My high-level challenges include:
• Reducing Signifyd Implementation Manager (IM) involvement in integrations (previously handled through phone and email communications)
• Providing a means for System Integrators (SIs) to be self-sufficient and provide tools for troubleshooting integration issues
• Reducing the time for customers to launch a live production environment
• Enhancing the original Developer Center design in order to maintain a consistent experience and visual language with the new Developer Tools Minimum Viable Product (MVP)
MY ROLE
I onboarded within the API integrations team in Q2 of 2019 while leading the development of the company's first design system. In Q3 of 2019, I lead design for the team for the initial launch of the Developer Tools application as well as the refresh of the Developer Center.
Initial discovery meetings and a first concept for Developer Tools had already taken place prior to my involvement, but was revisited when I joined the team.
My involvement includes research, planning for analytics, content writing, design direction and development, user testing, and task prioritization.
How Signifyd Works
2019
Source: Signifyd. How It Works. 2019.
Signifyd receives transactional data from the online merchant and reviews historical purchasing data in combination with a machine learning algorithm to provide a decision approval. If approved, the order would process as usual and is insured by Signifyd's Guaranteed Fraud Protection—should any future arbitrations occur. If declined, the online merchant can review the decision and determine their next action, which is not insured by Signifyd. Merchants can additionally request a second opinion from a Signifyd Fraud Analyst for more complex transactions that would also be insured if approved. In order to leverage Signifyd's algorithm, all transactional data fields must be mapped correctly through the integration process.
Signifyd Chargeback Recovery
2019
This diagram illustrates the need for a service that Signifyd provides. With 72% of issues relating to chargebacks that are unrecoverable, online merchants are historically burdened with validating transactions internally at great expense. By leveraging Signifyd’s Guaranteed Fraud Protection services, online merchants can focus on more important business matters while greatly reducing the cost of services relating to fraud protection.
Revenue Leakage and Effect on Business
2019
Source: Signifyd Revenue Leakage. 2019.
An early adaptation for internal risk teams included Draconian rule-based approval systems. Many of these systems are built with very basic guidelines and result in both false positive and false negative decisions—the latter which can cause customers to have a negative experience and potentially drive away future business.
DISCOVERY
STAKEHOLDERS Are the Key to Our Pain Points
The main challenge for the project was to reduce the integration involvement of Signifyd IMs. In order to gain more insight on pain points and get an understanding of needs, it was necessary to conduct a series of stakeholder interviews. During this exercise, I conducted interviews with the IM team manager, two IMs, and the Product Manager (PM) of the APEX team.
During my interviews, I found a number of recurring topics, which include:
• IMs currently spend a lot of time on integrations and could focus more on better business building areas
• Building relationships on first customer contacts are very key, but could be better if the process was easier and didn't require as much IM involvement
• IM Key Performance Indicators (KPIs) are quantified by the average customer time to go live, which can have many variables
• Lack of proper information from the customer in kickoff meetings (partially due to third-party SIs) is fairly common
• Strong need for a more professional developer experience with troubleshooting features
RESEARCH AND INSIGHTS
Metrics Reveal Pain Points
In order to understand current integration benchmarks, we looked to our historical data in regards to the time customers took to reach various milestones within the process.
Api Integration Metrics (Pre-Launch)
2019
Source: Chris Morris, Group Product Manager, Signifyd. 2019.
These metrics evidently show a need to improve the integration process. The difficulty in understanding the integration process may be a leading factor for users to start their integration. Bottlenecks caused by IMs dealing with customer support could potentially cause overdrawn data quality validation needed to verify integrations as well. And lastly, averaging slightly over two months to go live shows a need for change in order to scale the business. In some extreme cases, some customers even did not start any integration steps due to the difficulty in doing so.
Developer Tools Initial Concept
2019
Prior to my involvement in the project, there was an initial wireframe concept that had been created. The initial concept was more of a straw man for the information architecture and needed a much more development to include more features for troubleshooting purposes.
Original Integration Guide
2019
Original integration guide designed by Signifyd brand team.
The original design of the Developer Center, created by the brand team, was much more of an extension of the corporate website style guide and was not a consistent experience with the newly introduced Developer Tools MVP. Additionally, the content needed to be rewritten to be more approachable (originally one long scrollable page) and to have a consistent voice and lexicon language.
Deeper INSIGHTS
Observing Potential Users
In order to understand potential users better, we began to shadow a few developers that are familiar with integrations to unearth other potential pain points and their behaviors.
This exercise revealed that developers...
• have a need for digestible content
• prefer not to read long winded explanations
• often use Google to search industry terms; potential threats if a competitor site is referenced as part of the search results
• require sent and saved data to be revealed in order to troubleshoot integrations
• are used to managing multiple web browser tabs
• want clear code examples
• do not want to interface with people if they do not have to
• have a need for digestible content
• prefer not to read long winded explanations
• often use Google to search industry terms; potential threats if a competitor site is referenced as part of the search results
• require sent and saved data to be revealed in order to troubleshoot integrations
• are used to managing multiple web browser tabs
• want clear code examples
• do not want to interface with people if they do not have to
REFRAMING THE PROBLEM
Multiple Surfaces, One Journey.
After gaining a better understanding of the problem, success metrics were developed to align our goals with the leadership team. Our success metrics include:
Reducing average time for API integration to go live by 10%
Increasing average CSAT score for developer documentation from 3.5 to 4.0 and maintain or improve
Reducing Signifyd Implementation Manager time spent per integration
In order to reach our goals, I developed my own personal goals for the project that includes:
• Devising a linear plan for a multi-surface experience with the ability to allow users to access all integration resources in a curated and simple manner
• Reducing cognitive load as much as possible by making the content succinct and the visual language simple and unobtrusive
• Explaining the backend process so that users understand the integration requirements and are able to plan as needed
• Providing a first time user experience (FTU) that provides all relevant information to get started quickly
The solution
Developer Tools And Developer Center
The project resulted in two separate surfaces: Developer tools, a web management tool for integrations, and a refresh to the existing Developer Center, a microsite for all reference material relating to integrations.
Designed by me.
SPLASH SCREEN
Instructions for new users and introductory messaging to understand the application's features.
Designed by Maria Ortiz-Reyes.
FIRST TIME USER EXPERIENCE
Providing more supplemental information of what users should expect as part of the integration process.
Designed by me.
TEAM CREATION
Forms for test team (sandbox environment) creation that will curate integration resources based on selected details of the user's online store.
Designed by Maria Ortiz-Reyes.
TEAM MANAGEMENT
Integration management of online stores, which includes test (sandbox), in review (for data quality validation), and live (production) environments.
Designed by me.
DATA QUALITY VERIFICATION
Validation of data mapping transactional data to Signifyd APIs.
Designed by me.
JSON VIEWER
A feature that allows users to review sent and saved data in order to troubleshoot data quality issues.
Designed by me.
DEVELOPER CENTER
New microsite design system for integration resources and guides.
Designed by me.
THE Framework
Closing the Loop
When beginning to create the foundation of the two surfaces, it was imperative to create a service blueprint to create user flows that involve both surfaces as well as various backstage actions to act as a blueprint for features.
Designed by me in collaboration with Maria Ortiz-Reyes.
The service blueprint was not only a great foundation to further develop the two surfaces, but was also a great tool to align with other teams and get internal validation from subject matter experts.
Resources Information
Curated Integration Resources Modal
Webhooks Settings
Empty Table State
Data Quality Table
Data Quality Troubleshooting Details
Various sample screens from the Developer Tools application.
Because my efforts in creating Signifyd's first design system overlapped with my involvement with the Developer Tools app, it was more effective to move directly to hi-fidelity prototypes. This would allow the data to feel more tangible and also allow the team to move rapidly in order to meet the aggressive launch expectations.
Closer Look
If You Want to Be Taken Seriously, Be Consistent.
A large part of the project also included some other practices that are not highly illustrative. My prior background as a brand manager for a marketing team allowed me to see that some gaps needed to be filled in terms of content and visual language.
The content was rather long-winded and was not consistent in voice and language. Having reviewed marketing collateral in my past allowed me to revise the content to have a consistent voice and develop a lexicon list so that industry terms are denoted in the same manner and are explained as needed so that users do not need to search terms and potentially find results through a competitor website.
Device Fingerprinting section designed by me.
The initial concepts also needed to be developed further as we dealt with a bit of scope creep along the way as well as an expanded list of features following my involvement. It is important to note that some screens may seem rather stark, but were planned for other stretch goals that would occur in later releases.
The Validation Process
Design WIthout Validation Is Merely Art
Because our users for this project were a specialized group, we leveraged the services of a third-party researcher, Priscila Mendoza, who has a strong network for developers in various demographic regions and levels of experience. Because of our short development time frame, we tested a very rough, but pivotal point in the design while also testing the original Developer Center in order to support the decisions for the refresh that was being developed in tandem.
Initial user testing documentation by Priscila Mendoza.
The study included seven participants from different regions and experience levels and was remotely moderated. Each of the tests were also recorded and all notes were transcribed onto a spreadsheet so that they could be synthesized by the Signifyd team at a later time.
TASK PRIORITIZATION
Never Allow Your Ego to Diminish Your Ability to Listen
I personally reviewed each of the recorded tests in order to better understand the frustrations and the notes that were captured. Following this study, I was better equipped to synthesize the research notes.
User testing task prioritization by me.
I first started to color code the notes by roles that needed to make an approval decision. Then I organized the larger team in a meeting in order to prioritize tasks by: (1) must be resolved before launch, (2) enhancements for the next release, and (3) future enhancements.
Many of the enhancements for the initial launch were minor in design changes or moderate in content changes. However, we did receive great feedback on taxonomy changes and potential features that proved to be worthy of exploration for further releases.
KEY TAKEAWAYS
Habits Are Also Use Cases
Having had experience reviewing developer resources as a marketer in the past, it was humbling to revisit a similar project for the product team that revealed many great lessons along the way, which include:
KPIs from other teams can potentially be a great benchmarking tool
Thwarting Scope creep is crucial to manage expectations for all parties involved
Habits can provide many insights for workflow familiarity and flexibility
Service blueprints are both a great planning tool as well as an internal alignment tool