Learning about product design from famous SaaS founders

Editor’s note: This article features ideas and interview fragments from Jane Portman’s new book, The UI Audit.

When I quit my cushy position of creative director and started out as an independent UI/UX consultant 4 years ago, I couldn’t help my frustration with the startup industry. Nearly none of the products I designed ever saw the light of day.

That was my first biggest discovery: the software world isn’t all roses and unicorns.

My perception changed as my consulting practice gained traction—I learned that there are people who successfully ship their SaaS products and make a living off them. I was lucky enough to have some of them as clients. Amazing clients! But I still had to learn a lot about software design “in real life.”

UI/UX design is just a tool for product design, which is way more strategic. It’s often more important what we design, not how we do it.

This article should help you obtain a more realistic view of the SaaS industry. For my latest book, The UI Audit, I interviewed some super-successful SaaS founders, and today I’d love to share some of their insights on product design.

“Good enough” design will absolutely do the job

Everybody loves great design. But most often that’s just a declaration. When it comes to practice, design is a mere cog in a complex, multi-faceted business. And it’s not a critical cog. Just imagine other issues that founders deal with: development, marketing, sales, payment processing, security, payroll, anything else…

Great design can be a competitive advantage, while poor design can be a bottleneck in a SaaS business, causing customer churn and other problems. However, it’s never white or black. Founders often overlook design issues unless they’re absolutely critical. Or unless they make design a top priority—but it happens way less often than we think.

Are you familiar with the concept of good enough parents? This concept exists because it’s impossible to be perfect parents. Nor is it possible to achieve perfect design in a living product, especially if it’s a self-funded business. The true polish costs thousands of dollars and is only affordable for the industry giants.

Here’s what Ankur Nagpal, founder of Teachable (previously Fedora), says about software design:

“My key advice is, early on focus on making things not ugly. And then I think it’s 2 stages—first tier of design is ‘not ugly,’ second stage is making things beautiful. The good thing is, in today’s day and age there’s so many tools you have at your disposal to make things look not terrible. And I think that’s something you should totally leverage.”

Whenever the subject of UI design drives you crazy, please refer to these 2 lists. They will help you stay sane.

Here’s what UI design should do:

• Do what’s promised on the marketing website
• Get out of the user’s way while they’re accomplishing their goals with your software
• Satisfy the founder’s taste: it’s essential to sympathize with things that you create and sell
• Be decent-looking, in order not to scare customers off

Here’s what UI design shouldn’t do:

• Please everybody (it’s impossible)
• Be a piece of art (utility is way more important)
• Be unique (unique interfaces have a steep learning curve)

As a designer, do you see any place for your wild creativity here? Your life will get so much easier if you accept the fact that the world doesn’t revolve around your creative persona.

Product strategy precedes UI design

A product strategy defines what features you should build, and how you should build them.

Product strategy can be defined as a combination of 4 variables:

1. Audience: Who are your ideal users?
2. Goal: What big goal do they have in mind when they sign up?
3. Tasks: What tasks do they perform daily when they log into your web app?
4. Objects: What items do the users handle while performing these tasks?

Only when you fix all these variables (at least for one iteration) will you be able to build a focused, profitable product. First, you define what features deserve to be implemented. And second, you approach each screen layout keeping those key tasks in mind.

Here’s what Rob Walling, founder of Drip, says about their product strategy:

“We didn’t just want to build features—that doesn’t help. You have to have some type of vision for where you’re headed. And when we made the decision that we are going to become like a lower-cost, high-value marketing automation platform, then you instantly know what to build and what not to build.

You’re not going to build shopping cart software onto it, which some people are requesting. You’re not going to build an affiliate management program; you’re not going to build landing pages probably. You’re not going to build that CRM upfront. There’s a bunch of things that you don’t need, and then we can really focus on exactly what we needed to build.”

Research is essential

As designers, we often suggest certain design solutions based solely on our own opinion. Some founders take the same approach. But it’s doomed to fail—the way to build a successful product is to go out and see what’s happening in the world.

Here are the most popular forms of product research:

• Passive observation: Amy Hoy defines that as sales safari—exploring public forums in search of existing customer pains
• Direct interaction: Customer interviews and surveys
• Review of competing or legacy products

Calendly is a scheduling tool featuring the most spectacular design. Its design is amazing: very clean and functional. Calendly’s founder, Tope Awotona, reviewed over 30 scheduling apps during his research phase!

As a non-technical founder, Tope didn’t have unlimited resources to iterate on his product idea. So his goal was to build the right set of features from day one, using customer discovery and his own judgement.

“I didn’t outsource customer discovery to the engineers, I did it myself. I signed up for every single one of legacy scheduling tools. I became an expert at using every single one of them. I read through their support portals, what did people really like about the product, what did they hate about the product, what were they complaining about, what did they like, what did they not like. It’s very important to know what people already like in tools they have, and what they feel is missing or poorly executed.”

Only after extensive customer research Drip founders were able to nail their product positioning as “lightweight email marketing automation.” And these months were quite agonizing until the right decision was made!

“It was not an overwhelming majority, it was not like ‘Boy, 90% of people said you should go into marketing automation’–it was not like that at all. There was a lot of signals, there was a lot of noise in sifting through it. It was kind of like okay, so the first step is to build some automation stuff.

It was not obvious that we had made the right decision. I mean, when we first broke ground on this code, I asked folks if this is what they wanted. But you have 200 people, 300 people giving you their opinion and it’s hard to figure out what to build. So it was a good couple of months of kind of agonizing over which direction do we take this, what are we actually building here?”

Saying “no” to new features is the founder’s most important job

Dealing with the feature creep is the founder’s biggest challenge. Founders are bombarded with feature requests on a daily basis, and it’s their most important job is to say “no” to the vast majority of them.

Here’s what Tope Awotona of Calendly says about simplicity:

“Everyone sets out to build a simple product, nobody ever sets out to build an advanced product. But I think the challenge that you’re faced with is what’s really, really important: what 80% of the users can benefit from 80% of the time, versus what helps 5% of the users 5% of the time.

And the same people who would love the product for its simplicity want to add a lot more complexity to it. They say they want to keep it simple, which is true. But if you add in all the features, it wouldn’t be simple anymore.”

Here are the questions you can use to qualify new features:

• Does this feature serve your exact ideal customer, or does it make your product interesting to new customer categories?
• Does this feature serve the user’s big goal, or does it add other goals to their plate (even if solved successfully)?
• Does this feature facilitate the user’s most important daily tasks, or does it add other tasks to their plate?
• Does this feature breed new objects to be managed with the app?
• Does this feature solve a pain, or does it merely add an extra layer of polish?
• What are the development and support (!) costs of building this feature?
• Can this feature be easily replaced by building an integration with another software product?
• What part of the existing user base will benefit from this new feature and start using it immediately?

Final words

Hope you enjoyed these founder insights! If you’re interested in “real-life” UI/UX design of web applications, you’re welcome to learn more from my book, The UI Audit (free chapter and worksheets on product strategy are available). Use the promocode INVISION30 to get 30% off any book package.

The next time you work with a SaaS business, try to think beyond layout and typography. Consider a larger picture of the product. Try to put yourself in the shoes of the founder who has to juggle multiple things on multiple plates.

Try to get a more strategic vision! This will make you a wiser, more empathetic designer. This will help you get better clients and create the work you’re proud of.