Cavaco - The SaaS application for AI powered email marketing and content generation
March 2024 - January 2025 • Lead Product Designer
What's Cavaco about and what did I do?
Cavaco is SaaS platform that uses AI for all marketing content generation, including emails, social media posts, and more.
An all-in-one platform that created emails & SMS like Klaviyo, social posts like HootSuite, and marketing content like Canva. The goal was to be as AI first as possible and automate away the menial work.
I was the lead designer of the platform that designed it all. I worked with a team of about 10 engineers all based out of Argentina. They were very close team that were passionate about the things they build together.
These shots show the pattern we created where as a user would creating something, the AI assistant would be embedded in the page. Sometimes that would be in a manual builder versus the shot below, where the canvas in the middle displayed the AI's output.
First, I created the design system.
The directive was to use Tailwind out the box. So I started there and changed a lot of the elements to Cavaco blue and followed the rule of 8 for this project.
Typically on CTA buttons you may see a strong fill and white text. Since the specific Cavaco blue shade meant a lot to the Argentinian team and the founder, I opted for a black text inside, something a lot of Material 3 does as well.
Like everything I do, I deliver work weekly to move things forward. Everything is clickable and presentable in high fidelity.
As an AI product, I designed the generalized AI assistant chat pattern.
The first thing we did is figure out a common AI pattern that would persist on all pages where a user is manually creating something. I played around with whether the AI assistant should appear after a click of a button or FAB, or be persistent.
We landed on persistence. The challenge was definitely on the engineering side to make the output using AI actually be magical. It's very hard and everyone is working more towards it. The eventual goal is as an account has more assets, this gives this LLM more training data to work on for better outputs.
One thing I really wanted us to pay attention to is making sure the components we built were cleanly implemented. Good front end devs know and care, but it's always good to reiterate cleanliness. This is especially important we would be reusing this component in other places.
The plan was as the backend team continuously improved the output, the front end team would hammer on ahead. At some point, there would be a divergence where a user gets the magical moment that.
AI output > manual output
It's still not totally there yet, but the dev team did some pretty great work. The LLM models just aren't fully there.
From a development standpoint, the difficult part was to have the LLMs take an output, let the user ask for an update, then pass that back to GPT, return it back, and have it truly iterate without returning anything totally different.
We thought about traditional SaaS onboarding vs AI onboarding.
I created an onboarding prototype from a typical SaaS flow first. This includes a wizard to landing on the dashboard.
However, from my days in creating ecommerce sites in Shopify or creating my own products, I had a sense of what a startup company would want.
So I created this prototype as seen below, where a user who signs up from the landing page can simply enter in their Shopify store URL, and the system would crawl it, understand the CSS, use those properties to create a brand kit, and then reskin the template library to match those fonts and colors.
The goal was to get to the point where after signing up, they're ready to go and send out a branded email right away.
Since we created a reusable AI pattern, we thought about introducing them to the AI right away. So instead of a traditional SaaS flow, I designed this demo where they could experience the magical AI power right away.
After entering the URL, they could see the AI start to build their theme, import their product catalog, create the campaigns and more.
Rather than the user having to go into a different UI builder for each, the user could chat with the AI to make any modifications. We didn't end up building this into product, but I still thought it was a pretty neat idea.
People who try a new SaaS app may just want to skip everything and land in the platform before potentially bouncing. The idea was to slow that down, and let you get the "woah" moment - that dopamine hit that turned you into a paying customer.
Next, I designed a node editor for creating these campaigns.
From a research standpoint, this type of pattern has existed quite frequently out in the wild - a grid to see the output (with some kind of thumbnail), and a node editor.
Since our pattern was to put the AI assistant on the right, the nodes would be dragged and dropped onto the left. The other UX considerations were:
(a) having the nodes snap into place vertically (as to opposed to horizontal or freeform
(b) node actions all in a (…) icon
(c) for simple nodes, they could open in a drawer whereas more complex ones could open in a full modal
One tricky part was variants. For each action such as sending an email or SMS, the user could create multiple variants per block. Pattern-wise, I was inspired by Figma's table of interactions to a component in prototype mode. It helped me wrap my head around how I could present it:
(a) table of
Users could create themes that affected the look and feel of their emails and other brand assets.
The onboarding process would automatically create the theme for the user based on ingesting their website. However, users could still create their own.
Rather than creating a basic list page, I thought about what elements we could display in a theme before drilling in further. Here in the UI, the colors, fonts, and buttons could help the user get a sense for what theme it is.
In addition to creating things like colors and fonts, we added the ability to add tags to the theme. In fact, adding tags in the UI became the norm for every object. This helped the AI understand what to refer to when creating assets.
Although in the future, I'd imagine the better UX would be to abstract that layer away altogether to simplify things, and the AI system itself would know/learn what to use, instead of relying on manual user tagging to assist in that.
I'd typically create all the states for these components to hand off to engineering.
I designed the social media post builder UI.
The founder wanted to expand the platform to use AI's text & image generation capabilities for social media creation. The interesting part we talked about is if we want to create them one at a time or do a bulk creation mechanism.
In the UI, the user could create and preview across all of their social media accounts in one go. Additionally, they could use the AI Assistant for any image or text generation.
Blog creation was handled separately as there could be different heading sizes, images specifically in the article location, and more. The truth is, a lot of the WYSIWYG functionality could be handled by products like CKEditor or TipTap. These were nice out of the box solutions that looked and worked like Notion, making our lives much easier.
One of my bigger efforts was designing a video shorts editor like CapCut. This didn't make it into production as the engineering effort was too great for a startup. However, we explored that possibility. I was very inspired by CapCut & Veed.
Canva also has an excellent shorts editor. However, I omitted a lot of features in order to simplify the experience. For example, there is just 1 timeline view at the bottom and a user can only pull from content previously uploaded to their content collection library.
Bring it all together in the calendar view.
Users who manage all of their social media posts want to do so from one place in a calendar view.
When I designed this feature, I thought about and iterated on many things:
(a) general UI of the calendar grid
(b) color schemes of each event (are they filled and white like Google Calendar). I used the same fill of the status pills (gray = draft, light blue = complete, green = running/scheduled)
(c) Where do I put all the unscheduled stuff. Even though the pattern was to open modals on this page, I made that list a drawer, so the user could see the context of the calendar and drag and drop it into the interface.
What are other ways we can use AI?
The application needed notifications, so I followed the classic pattern of having them appear in a bell in the upper corner. This ultimately would lead to a notifications list page where they could be managed.
The idea was to ensure the notifications handled basic events occurring in the app (ex. sign ups, or campaigns executing), as well as analytic events.
However, at its basic core, the AI entry point is simply a type-in field. The pattern was to proliferate that AI Assistant all throughout the product. But there may be use cases where the AI simply requires one string of text from the user, before it goes off and executes actions in an agentic manner.
So I designed a list page for that function. Users could get a question from the AI with some context, and enter in a string. The AI from there will understand, and do the action in the background.
We then took it a step further and began discussions for support for other channels. Users may be busy doing emails, or on their phone. Those same questions from the AI Agent Tasks section can be asked on any platform. The AI will understand the string response, and take action.
The goal of this feature was to understand that the industry is moving towards having SaaS applications that use AI to operate in an agentic manner. This idea was to get ahead of the trend.