Confession time: I can’t code my way out of a paper bag. It’s not surprising, though, that there are plenty of other SaaS founders out there just like me.
We’re the customer-facing founders, the ones who are so hyper-focused on our customers' needs that we never had the time to learn our JavaScript from our Python. The problem is, when it comes time to deliver, we have to rely on our dev teams, who have extremely limited time and resources.
I wasn’t willing to go that route when it came to building Candu. As the first no-code native web builder, we help B2B companies build onboarding experiences. So, we obviously had to get our own onboarding right. That meant gathering feedback and iterating on our customer dashboard again and again…. and again. The development cycle would only slow us down as we made changes based on customer feedback
Here’s how we crafted Candu’s initial dashboard without coding a line.
Version 0: The “No Customer Dashboard” Approach
Strategy
Candu’s very first users didn’t experience a dashboard at all. Rather, we dropped them right into the product, on an editor page that prompted them to start creating content. After conducting hundreds of user interviews, we knew that this was our magical moment. Once users began creating content, they’d be hooked, or so we thought.
Learnings
Unsurprising to anyone who has worked in software, dropping users directly into the app left them feeling adrift, and they would audibly wince, no matter how intuitive our interface. We knew we weren’t giving enough of the why of our product, but we also weren’t sure what to show them.
We designed a fancy interactive installation checklist, but that would need to be custom built, and it was fairly developer-focused when our core user is non-technical. Instead, we decided to dog food our own product and add a Candu canvas to our home dashboard. Now, we could QA our product and improve our user onboarding simultaneously. Synergy.
Version 1: The Candu-centric Customer Dashboard
Strategy
First, we tried to focus our audience on what we needed from them. That meant encouraging our beta testers to give us feedback while making them feel appreciated.
We launched a closed beta, and I invited (hounded) new users to try out our app. The dashboard, therefore, sought to get them on board as beta testers who felt comfortable jumping into the product while directing them to leave the type of feedback that would be most valuable to us.
Content-wise, Version 1 of the customer dashboard welcomed our beta testers and thanked them for their help. Then, we tried to give them a “mission” to focus their attention on one part of our app. On the right-hand side, we created cards to encourage users to send us feedback or submit bugs.
Learnings
As it turns out, this dashboard excited no one. The missions we created just weren’t relevant to most users, and no one reported bugs or offered feedback. The cold-call approach to signing on beta testers just wasn’t working. No one understood how Candu worked or what to do with it.
We were still thinking about the content from the perspective of what would serve us best, not what would serve our users. We knew then that we would have to learn what our users wanted to accomplish with Candu in order to create a more effective dashboard.
Version 2: The Pretty but Dumb Customer Dashboard
Strategy
To gather better feedback, we refocused our beta program on the design partners who’d been with us from the start. These folks needed to onboard their users and were motivated to help us.
We realized that the app’s blank canvas was overwhelming to many of our users, so it made sense to provide them with some pre-built pieces of content. We wanted to go above and beyond for our design partners, so we created a custom template for each that included their company logo and a welcome message. We also added our faces in Contact Cards to humanize the app. We created a short bulleted list of what to do to get started, and included all of our newly-built templates below.
Learnings
Unfortunately, we were so focused on making the dashboard visually appealing that we sacrificed usability. Our beta testers were overwhelmed by the 12+ templates we provided, so we were left with the same problem we started with: people simply didn’t know where to begin.
We also heard from users that creating content was interesting, but it felt like the end of the road. They couldn’t conceptualize how the content would fit into their own product. It didn’t help that Candu’s “Preview” button wouldn’t work until Candu had been installed. That broken button was a sticking point for a lot of users, and we heard of their disappointment loud and clear. Clearly, we’d have to help them quickly understand how Candu fit into their product — and work lives.
Version 3: The Customer-First Customer Dashboard
Strategy
Based on what we learned from Version 2, we made changes to both the product and the content. From a UX perspective, we moved the templates out of the dashboard, so that users could see the full library whenever they went to create a new tutorial. Then, we bucketed the tutorials by customer use case so that users could choose from a smaller set of relevant options. We also pivoted some of our engineering resources toward creating a preview extension, so that users would be able to preview their content without installing Candu.
On the content side, our product designer took the lead in refining our Candu dashboard.
We added key action cards with the top four actions for getting started alongside beautiful illustrations, and we limited ourselves to showcasing our three highest performing templates.
Some users had commented that they’d be more comfortable in the app if they could learn more before jumping in, so we added some links to documentation and resource shortcuts.
Finally, we improved our dashboard by embedding other, smaller dashboards. Instead of creating a new dashboard for each customer, we created one dashboard with an embedded section, which allowed us to change out the welcome messaging by account. This meant we could continue to iterate on our content without losing that personal touch.
Learnings
Now we were getting somewhere! Our design partners were happy to see our customer dashboard change so quickly and easily, and they were finally clear on what actions to take when they entered the app.
But they still weren’t sold on Candu’s added value, and let’s face it (almost) no one wants to read documentation to figure it out. We needed to help them quickly understand the product, the value prop, and how to get started. The dashboard was a step forward, but it wasn’t getting our users all the way to where they needed to be—to value.
V4: The Ready for Launch Customer Dashboard
Strategy
In our latest iteration, we’ve kept a lot of the good stuff from the prior version and added a product explainer video to help users orient themselves. We’ve also added data tracking, allowing us to combine the qualitative feedback with quantitative reporting on the nearly 500 users who signed up for Candu in our Product Hunt launch.
Learnings
We’re still waiting to see what our users think of Version 4, but what we have learned is that creating the best experience for our users is iterative. The hours of user interviews we conducted before publishing our first dashboard couldn’t compare to the feedback we got from users once they were actually in the app. Show beats tell. We completed five versions in less than two months, and being able to test, learn, and iterate quickly helped us get to a product we’re truly excited to share.
Log into your Candu account or try it out for free to see the latest and to start publishing, testing, and iterating your own user experiences. While we love what we’ve built, we’re excited to keep iterating and improving based on your feedback.
