Custom Fields
Improve data quality within Recurly by allowing merchants to add their own custom data attributes (e.g. system information or customer-specific account information) to account or subscription records.

Why did I pick this project to share?

Though it might not be one of the largest projects I’ve worked on, I believe it’s a good example of some of the types of things I use in my process. My process isn’t always the same for every project either. It’s really dependent on the level of knowns and unknowns, and solving for those unknowns.

This project utilizes a UI Component Library that was built at Recurly before my time. It’s in need of a visual refresh, which is on their roadmap for this year.

Kicking Things Off

Initially I talked with the product manager on the project to get a little background of what the project to figure out where to start. It turns out he had already pulled some merchant feature requests from Salesforce, and did some existing calls with merchants about the feature. He and I opted to schedule a meeting with the developers who would be working on the project so we could review the feedback and start identifying the use cases.

This team consisted of a product manager, three developers, and myself. 

Meeting Touch Points

  • Reviewed merchants feature requests on Salesforce
  • Reviewed merchant interviews conducted by product and customer support. 
  • (I wasn’t involved in these this time, but I often try and sit in on this with product.)
  • Reviewed how competitors and other products use custom fields.
  • (I wasn’t involved in collecting this info, but I often do depending on the project.)
  • Put together 10 use cases from the merchants’ feedback.
  • Brainstormed what this functionality could look like from the API level,  UI inside of the Recurly admin console, and storage structure inside of the database. 
  • This brought up a lot of discussion around custom fields only being used via the API or if we actually needed to support the ability to add and use custom fields in the UI. (A large number of our merchants, especially our VIPs use the API to do a lot of things in our app.)
  • Identified open questions we needed to answer.
  • I suggested we put together a survey for the merchants that have showed interest in the feature and get some answers to these open questions before we move forward.

Coming out of the initial kickoff, I started to put together the open questions into a merchant survey on Google Forms with the product manager. 


Survey Responses

We ended up sending this out to 38 merchants and ended up getting 31 responses. We don’t always get this kind of turnout for a survey, but in this case we got lucky. 

The answers we got back helped us identify that we needed to support this feature in both the API as well as the UI in the admin console. It also helped us to understand some of the use cases more specifically, as well as answered some other open questions we had.

I met with the team and we used the responses to help us finish identifying all the requirements.

It also helped influence some business rules around the number of custom fields a Recurly merchant can create based on their Recurly plan.

Starting on Designs

I identified the high level areas of design needs and impact and started there.

  • Configuration (Create/Edit/Delete and view configuration details)
  • Accounts (View/Edit custom field value depending on configuration)
  • Subscriptions (View/Edit custom field value depending on configuration)

Design Exploration & Thinking


Configuration