Context: Springbot offers a suite of digital marketing tools for ecommerce businesses. Their email editor is used for automated and one-off email marketing campaigns.

Problem: The biggest source of churn was due to difficulties with the email editor. Users found the editor was too difficult to learn or took too much time. Springbot’s users want to increase conversions from their email marketing campaigns, but they do not have time to invest in a long-term marketing strategy and design.

Project limitations: Springbot’s email editor was built on top of a framework called GrapesJS. This required the design team to frequently check in with the engineering team. There were often features that could not be removed (or added) without breaking other parts of the editor experience.

I gathered a list of users who churned because of Springbot’s email editor and watched FullStory sessions to see first hand what specific frustrations they experienced in the editor.

Additionally, our most active users belonged to a team called “Campaign Services” at Springbot who designed emails for customers subscribed to premium level packages. I did a series of in-depth testing with them and recorded their feedback.

From there I created a list of recommendations to discuss with our developers grouped into common themes in user frustration:

• The user struggles to orient themselves in the email editor. Settings weren’t organized in a clear hierarchy. The user often had to jump between different panels in the middle of a task- pulling them out of a workflow.
• Due to “developer-friendly” language (e.g. padding or corner radius) and UI, first time users often had to play around with every single setting before they learned how to manipulate elements on the email canvas… and often didn’t remember what they did in successive sessions.
• Lack of visual clues around empty states, focus states, etc resulting in frequent user error.

In my research, I found accounts who churned in their first 6 months were clicking on average 2x as much in the email builder as those who stayed with Springbot after 6 months. Suggesting those who were satisfied with the email building experience were able to build an email with less effort.

In order to decrease churn, we would need a simplified email editor experience requiring less time and fewer clicks from our users. This was especially important for first time users as churn rates drastically increased for those who failed to send an email in their first 30 days.

After reviewing the list of recommendations with the engineering team, we organized changes into three phases:

1. Remove features.
• We would strip out underutilized, redundant and distracting settings that could instead be replaced with “smart defaults” or templating.
• This would offer an immediate value to our users while we invested in more intensive design updates.
2. Update components for simplicity.
• As an expansion on smart defaults, we would design components within the current UI that offered pre-templated options to our users rather than forcing them to manually adjust every dimension of their email.
• This would afford us the ability to learn as we invested in bigger UI changes.
3. Update the UI.
• Consolidate multiple settings panels into a single panel that changes views according to the actions the user is taking on the canvas.
• Basic usability updates like adding different states, making buttons larger/easier to click, utilizing the additional space for longer inputs.
• Reorganizing accordion options from most to least used settings.
• Adding interactions to intuitively guide our users along a flow, keeping them focused on making one change to one component at a time.

Because we were updating the editor in phases, we adapted the final designs according to realtime user feedback.

This allowed us to tactfully adapt our strategy for more “expensive” UI updates.

Our "prototype" (really our iteration on the live editor) lived in beta for 3 months. The feedback was overwhelmingly positive.

From users, we got the response every designer wants to hear, both validating our current work and our future plans:

There were a few bumps in the road before we could do a full launch. In some cases, we’d simplified a little too much where users wanted more control. An example was our product module which enabled a user to drag in a product directly from their catalog. Formatting this module was often a source of frustration for our users.

We created a templated version of the product module with a multi-select so that users simply had to show what they wanted to display. The issue is that our users wanted more customization over the text beneath the product. Our solution was to break up the product module into smaller editable components once dropped in- rather than forcing the user to select from preformatted dynamic tags to display.

Our time running the beta helped us to look more deeply at UX like this, which might have otherwise been obscured by more obvious points of frustration.

On the stakeholder side, leadership said our approach made for the smoothest release the company ever delivered in nearly a decade of existence. Typically dev and success managers found releases to be extremely stressful and full of unexpected problems.

This got design a “seat at the table” and changed the way engineering worked with design moving forward.

Personally, I learned a lot about how the development process worked in the past at Springbot, and I was able to identify ways that design and engineering could better collaborate together. The successful release helped build the trust needed for me to sit down with team leads and begin developing a shared design language. Which was a conversation that ultimately led to the foundations of a design system and separating our frontend from our backend so that universal changes could easily be made across the app.

Context: Nelo’s app enables people to take out small loans, which can be used as credit to pay bills from the app. Their team was preparing for a new release, which would use their technology to facilitate a “buy now pay later” (BNPL) product. With BNPL, users can make a purchase now which they pay back in installments.

Problem: Most BNPL users will interact with Nelo's brand for the first time after making an online purchase. Nelo needed a dashboard where users could repay their loans, and learn about Nelo's credit system within the contexts of the BNPL model.

Project limitations: One week deadline, no research team, no design team. (Yupp, it’s a start-up!)

Nelo conducted initial research to identify their target user. Key insights included:

• Only 9% of Mexican residents have a credit card. For the 91% of Mexican residents who do not have a credit card, Nelo would be their first opportunity to pay in installments.
• It was predicted users would access the dashboard through a mobile device only.
• It was likely users would primarily use Android and Samsung devices.

Because this is an unexplored market in Mexico, I built on this research was guided primarily through competitor analysis. I analyzed the user flows of three different BNPL services. Then I collected data via reviews of existing services. Here’s what users liked about existing BNPL service:

• They're accessible to anyone with a phone.
• It was easy to understand how the payments work.

Here’s what users disliked…

• Users experienced frustration when they felt they had been “tricked” into accruing fees.
• Not every BNPL service provided users with a “credit limit” upfront. Users were surprised when a purchase was rejected (Nelo already offers this feature in their mobile app).

For the stakeholders, there were two primary goals:

• Increase compliance to loan repayment schedules.
• Increase downloads by upselling the Nelo app.

The challenge would be creating a seamless experience between the BNPL model and Nelo’s credit model. To guide this process, I drew out the existing user flow, to which I would upend features of the BNPL product. This way the two different products would mirror each other.

Stakeholder’s goals were in near perfect alignment with the user needs discovered during the research phase. To help make the meeting of these needs possible, I prioritized features on the dashboard as follows:

• Clear entry into repayment flow with clear due date.
• A CTA introducing credit limits within Nelo’s app.
• A visual indicator of how far along a user was into repaying.
• A detailed view of purchases and a repayment schedule.

While nuanced, there were differences in displaying loans tied to purchases, rather than bills paid from an existing credit line. I met with Nelo’s engineering team during their daily standups to ensure their current data model would map to these features.

Due to time constraints, I went directly from pen and paper into creating a mid-fi wireframe.

I started by building a responsive component library in Figma using an 8pt grid. Nelo needed a UI that aligned with their current branding made up of components that could quickly be adapted for new features or user feedback. This library would be a starting place for a design system as the product continued to scale.

Out of this library, I built a mobile dashboard and moved swiftly into testing before touching desktop wireframes.

I used guerilla testing on users who were unfamiliar with Nelo’s product. Users found the product clear and intuitive to use with the exception of this feature…

“What are the dots? Why can’t I click these?”

The dots were meant to create a visual representation of how far along a user was into repaying a loan. To amend the confusion, I increased the size of the dots and added numbers to the middle of the circles. This tested much better.

There were two points of critique when presenting to the stakeholders.

• I missed an entire flow for viewing payment history! Oh no! But not too big of a deal since it was only 2 additional frames. It helped me realize that I needed to be more thorough during the definition phase.
• Stakeholders asked that I further build out the detail view as an additional way of sharing the user’s progress as late-fees and early payments often created a customer support need. This chart was the solution we developed together.

This was the first time I ever designed something of this scale without a design team, and I was pretty intimidated! I love working with other designers, but working without a design team really did emphasize the value of having a design methodology. Some of the lessons I learned…

• Creating a design system is worth the upfront effort, and I really don’t think it’s ever too early to get started. Especially when assets and variants in Figma make it so easy to make small tweaks as you go along. (This was especially good to experimenting with the UI real time while meeting with stakeholders)
• Collaboration with other teams during the design process is so important! It paid off when communicating with engineers. If I could have done something differently, I would have involved more people during the definition and synthesis phases. Particularly when creating a user flow and product requirement.