Contradicting My Own Design Advice
How I filled an empty state full to the brim and what I learned from watching it overflow…
In my last post, I explained:
We just launched a new product. New to us. New to the industry.
This new product being…
The Template Builder…our crack at streamlining the back-and-forth paperwork process that hundreds of businesses waste hundreds of hours on. This product lets users add fields on top of their existing document to create one template that is reusable and easy for their recipients to fill out.
For the past few months, we’ve been trying to figure out the best way to introduce this product. This is just one of our many attempts.
Look here, look here!
Before we keep someone’s attention, we must first capture it. How? Well, people typically want to understand what’s relevant to them; and it’s easier for people to imagine how a new product can fit into their existing workflow than how their existing workflow can accommodate a new product.
So before we spew out messaging around our solutions and value props, we’ve got to call out the relevant users with workflows we can help streamline!
My Proposal
Of those who discovered the Template Builder, almost all came from spotting this page — a powerful leverage.
The original empty state has no mention of user groups so lets:
- Highlight our 3 main user groups: Business, Real Estate, and Human Resources
- Provide the most relevant sample document for each respective user group to convey “this is the type of document you need to upload” for the Template Builder to make sense
- Convey that there is a recipient role because in user testing this crucial point was often missed
My design ended up looking like:
My Justification
I thought this proposal would work because:
- More qualified uploads could come from more users realizing this product is relevant to them
- More qualified uploads could come from users seeing examples of the right types of documents to upload
- At the very least, I could filter out the wrong types of documents to upload
And…It failed!
In the 1–2 weeks that the new empty state was live, almost no one uploaded a correct PDF, our main success metric. Compared to the original empty state, our click rates on the “Try a Demo” CTA went down by about 50%, a secondary success metric.
Yikes. 🙃
What went wrong?
Hindsight is 20/20 so let’s backtrack. I’ll never know for sure but I did embarrassingly realize…
I went against all the advice I gave in my last post! Ha!
Advice #1: “If everything is important, then nothing is.”
When I was drafting what content I should include, I made a table to organize what relates to what and noticed a “formula”.
I thought:
Hey! Wouldn’t it be cool to have some fill in the blank layout like Mad Libs?
This could suggest that there are many different ways to use the product and the user can plug in their own use case.
The copy, below on the left, identified the user, their document, and their recipient. In the next iteration, below on the right, I wanted to also address the pain point.
Then I wanted to also specify what types of documents a user should be using with the Template Builder:
The example document, the recipient, the user group, the pain point, the types of document a user should be uploading — all thrown into the mix. I thought this was such a concise and efficient way to get our message across but the copy was trying to hit so many points that nothing landed.
Advice #2: Think inside the box. Use the constraints of what you’re working in to your advantage.
In the final version that went live on Formswift, I literally went outside the box. In hopes of being eye-catching, I think the visuals actually became distracting.
Because I didn’t use the constraints of a traditional empty state, typically a couple sentences of copy and 1 main CTA, my empty state resembled more of a landing page. This might’ve caused a disconnect —
Expectation: This is a lot to consume and a lot to interact with…
Reality: No, actually, it’s just an empty state.
Playing off the physical constraints of an empty state box, I could’ve created something like:
Advice #3: Make the obvious OBVIOUS.
What isn’t apparent right away is that the dropdown options are connected.
If a user clicked “Rental Application” in the first dropdown then “Tenants” would automatically get selected. The copy in the green CTA would also automatically change to “Try a Landlord Demo.” Each of the 3 different CTAs directs to a different sample document.
Because this relationship isn’t clear until a user clicks around (and chances are, they wont), it seems like there’s a lot of work to be done. The original empty state had 1 “Try a Demo” CTA. Now, 3? As Hick’s Law puts it:
Increasing the number of choices will increase the decision time logarithmically.
Other possible concerns: does it look like only these 3 documents would work? Does it look like we’re making the documents for you? What if the user doesn’t identify with any of the user groups?
The more chances for assumptions, the more chances for users to mis-assume and click out.
Final Takeaways
- Sometimes, in this case, less is more!
2. It’s important to separate the idea from the execution. Although we learned that the highly-illustrated-double-drop-down-empty-state didn’t work, that doesn’t mean user personas don’t!
3. Last but not least, take this as a chance to reflect on your own work. Realize how challenging it is to remain consistent in ideals and how productive it can be to identify not just what failed by why.
Onwards and upwards! 📈
Get Your Hands Dirty
The Template Builder is very much here and alive if you want to play around with it. You’ll need an account first — it’s free!
Thankful
For my team — especially Elisa, Ronnie, and Brittany. ❤️
