Design guidelines for non-designers: Make your product stand out

Back in the day, design wasn’t too big of a deal. As long as the product worked, it didn’t matter that much what it looked like. Products were much more utilitarian. Users were willing to jump through hurdles to get value out of them.

It’s very different today. There’s much more competition on all fronts, and users have much less patience for poorly designed products. Any friction in your product may cost you a customer.

I'm a product designer and co-founder at Canny and in this article, I’ll explain how non-designers can apply basic design principles to software products. For each of the guidelines below, I’ll give an overview, an example, and talk about how you can apply it in your work.

Let’s dive in!

What it means to have a well-designed product

The overall design consists of two equally important parts: UI (user interface) and UX (user experience).

UI’s goal is to clearly communicate to the user what's important. Any user interactions should be very straightforward. UI is also about the look and feel of the product. Put simply, the user interface is what you see in a product, such as navigation, inputs, and icons.

UX combines all aspects of a user's experience: usability, usefulness, desirability, brand perception, and overall performance. You consider the entire experience of interacting with a product, including your feelings.

Contrary to popular belief, design isn’t just about making things pretty. Good design is about solving real problems, first and foremost. This is especially important in B2B products where your customers are paying for your product to do a job.

Our goal at Canny is to build a product that is a joy to use. We want to bring users to their “aha moment” as quickly as possible, with minimal distractions. In other words, we need to make it super simple to use.

Now let’s explore how you can get your product to that state.

Before you do any design work

Sometimes, you just want to jump in and start designing. Try to fight that urge and start here instead.

Define your target audience

You need to know your target audience extremely well in order to optimize experiences for them.

If you’re not sure how to define your ICP (ideal customer profile), try this: Think about who’s most likely to benefit from your product. Take the time to really dig into their demographics, psychographics, and personality. The clearer you can get, the better.

Consider alternative approaches

Any given problem can have many potential solutions. Do early due diligence to think through and refine your approach. Ask yourself:

• Is the problem a byproduct of another issue?
• Is there a workaround solution?

Learn to say “no”

The reality is—you need to be selective. You can’t (and should not) build everything. That’s the art of prioritization — selecting the most impactful ideas.

Occasionally, we have to push back on ‌requests that we get from customers or other team members. Sometimes, a feature just isn’t a priority based on how much effort it would take and/or the impact it could have. Other times, features don’t add to the long term vision or might negatively impact overall user experience.

Design guidelines

Now that we’ve done some due diligence, let’s get into some guidelines.

Understand use cases to define the scope

Effort is required to fully understand the underlying problem you’re solving. Try the following:

• Collect user feedback
• Ask your users questions (through surveys, interviews, etc)
• Gather data and look for patterns

Remember: don’t make the scope too large right away.

Aim to build an MVP — minimum viable product. As you’re defining it along with critical use cases, ask yourself:

1. Does this have to be this complicated? Can we simplify for now?
2. How are most people going to use this feature? Can we design only for that use case?
3. What are alternative solutions and what are the tradeoffs between them?
4. Where is the potential for user confusion/error?
5. How would the design change if we removed/added X functionality?

💡 Tip
Consider the Pareto Principle: How can you solve 80% of the problems with 20% of the work.

Here’s our own example

We decided to build a CSV import feature. Instead of supporting all data structures, we started with posts only. If we wanted to incorporate users and votes as well, it would’ve been way more complex.

To support this decision, we saw that teams who wanted to import ideas didn't have associated user information anyway. We have the option to expand the functionality later, but the MVP is sufficient for most people.

Win: Faster to build, simpler experience.

Here’s how you can apply this to your design projects

Before designing, do your research. Ask your users questions, look at data, and really ask yourself: Which functionality is absolutely crucial? Then strip features down to their most basic form. Less is more!

Don't reinvent the wheel

“Good design, when it's done well, becomes invisible. It's only when it's done poorly that we notice it," – Jared Spool

This quote is so true — design exists to help solve a problem. As a designer, the more you can make the design get out of the way of the task, the better.

Don’t overcomplicate your design. The more unfamiliar the interface is to the user, the more potential for confusion. Unfamiliar design patterns also hurt conversion rates. What’s more important (especially in the SaaS industry) than conversions?

The bottom line is: “Don’t make me think”. Avoid making your users question anything.

Just for laughs, check out this intentionally bad UI Reddit thread for some examples of what not to do.

Here’s how we keep the design simple at Canny:

If you check out our website, you’ll see that it’s pretty similar to other SaaS landing pages. We’re not trying to win a website design award; we're trying to convince people to sign up for our product. Elements of our landing page are very common in SaaS:

• A logo always sits in the top left corner and goes to the home page when users click on it
• The main navigation is at the top or left side of the screen
• Important elements are above the fold

Here’s how you can apply this guideline:

The web today is extremely mature, so use that to your advantage. Look to brands that are similar to yours and ones that you admire for inspiration. How are their landing pages structured? Stick to common elements like tabs, toggles, dropdowns, primary/secondary buttons, etc.

Get rid of any friction

This point goes back to simplicity and is especially important in user onboarding. If something within your product onboarding causes any confusion, your users will feel frustrated.

If customers cannot complete their tasks in your product, they're not reaching the value they want. This will lead to churn.

How can you prevent that? Remove distractions and focus on helping them complete their task. Decrease the chance that they could make any mistakes.

Let’s go over an example.

Imagine a checkout page. If you’re a user, all you want to do is quickly complete your transaction.

How can you, as a designer, make that happen? Remove unnecessary navigation and distracting text, while including things that add clarity.

If you’re finding that some of your users aren’t acting the way you want them to, this is a clear signal that you need to optimize that design. The design process doesn’t end when flows/features are launched. Take time to revisit experiences to see if they could be optimized.

Here are a few ideas to get you going:

• Try tools like FullStory that show you what users are doing. Is there any unnecessary friction? Free tools like Google Analytics can also help uncover friction points.
• Can you reduce the number of clicks?
• Can you eliminate distractions?
• Can you A/B test various parts to optimize even more?
• Can you conduct a usability test to find issues?

Usability tests can help answer several of the above questions. As you’re running usability tests, ask your users to think out loud. Take note of any confusion.

Be prescriptive

Sometimes, there are many ways to complete a task. Every so often, it's best to take a stance on how it should be done instead of trying to support every use case.

This goes back to minimizing the chance of error. If users don’t have options, they’re much less likely to make a mistake and get confused within your product.

We always aim to reduce complexity by being prescriptive with our designs. Instead of offering endless flexibility, we design for the fastest path to value for our users.

Consider tools like Jira or Salesforce which are very powerful, but also very complex. They win a lot of business because of how flexible they are. However, building new features gets exponentially more complicated as existing features might impact new ones.

Especially in the early days of a new product, you’ll want to optimize for speed and clarity.

Remember: You can always add more flexibility to your product in the future. Avoid complicating it right off the bat.

Here’s an example of what we did at Canny:

Initially, we had a set of default statuses available. The majority of customers were satisfied with these and it kept the experience simple.

It wasn’t until years later that we started supporting custom statuses which involved:

• Building a status management feature for admins
• Looking at how statuses appear in different views
• Updating integrations that involved using statuses

Not to mention that we now need to consider custom statuses for future features we build. The complexity snowballs very quickly.

Limiting our scope to the essentials at the beginning was the right move. From there, we were also able to collect feedback to inform how we needed the custom status feature to behave.

Here’s how you can apply this to your workflow.

When building new features:

1. Think about your core persona and the goal they’re trying to reach. What’s the most optimal/most obvious path to that goal?
2. When engineering, consider building things so that you can easily expand functionality down the line.
   Remember: It’s much simpler to add functionality later than to strip things down

Optimize for most common actions

Powerful products can be simple. You can support a ton of powerful functionality without making the product complex.

Here’s how: Put the most common actions to the forefront and tuck away the less common ones.

Here are some obvious examples:

• Navigation is very common and should be available on every screen.
• Settings aren’t typically configured very often. Tuck them away in a predictable place.

How can you figure out which actions are more common than others? Get to know your users. The better you know them, the more obvious it becomes.

Canny example: Two of our top-level pages in Canny are the feedback and users pages.

On both pages, our customer performs a common set of actions, sorting and filtering data.

So we have these actions available for ‌users in the left sidebar. Putting similar types of functionality in the same place (even though they're different pages) helps with predictability and understanding of your product's layout.

Everything else (like settings) is hidden in the settings tab (which is still easy to find).

How can you apply this?

1. Make a list of tasks that your users need to complete
2. Rank the tasks by how often they need to be performed
3. Think of navigation as a separate feature

• Which navigation should always be accessible?
• Which navigation only needs to appear on certain pages?

4. Group similar functionality together

• When a user is doing a task, what other options should be available to them?
• Divide pages into larger sections made up of those groups (for example, a set of filters)

Be helpful but not annoying

Obviously, we want our users to use all of our features. Especially when we release new ones, we want our target customers to adopt them.

There are various ways of bringing attention to new features. The key here is to be helpful in the right context. This goes back to understanding your users, knowing where they are in their journey, and serving them. In other words, show them what they need to complete the task at hand.

Here’s how we do it at Canny

Instead of doing tooltip product tours/walkthroughs, we have an onboarding checklist. We find it to be a great way to help our users onboard (at their own pace) by using the product.

From there, we show helpful tips throughout the product (but only where it makes sense).

We supplement this with our drip campaigns (email and in-app messages) which highlight certain features, depending on how far along each user is with onboarding.

Want to try this yourself?

Here’s how you can do it.

1. Break down your customer journey into phases
2. Align features across each phase. Ask yourself: when do ‌customers need to know about a feature? Right away? After a certain action? Only if…?
3. In-product education is great when the timing is right. For instance:

• Surface tips that make sense on the page the user is on. Near the relevant feature is usually a good option.
• Don't leave null states completely blank. Use them as an opportunity to educate or point people in the right direction.

Another thing we find very useful is dismissible new user experiences (NUXs). Those don't go away until the user has acknowledged it. It’s a good way to educate without being annoying.

Random popups are an option, but they’re not a great experience and you risk frustrating your user. Being helpful at the right time is what we’re aiming for.

Design’s not about you

What do all the things we talked about have in common? It all comes down to simplicity.

It is possible to have a really powerful tool while keeping the UX simple and delightful to use. Also, it's easier to add functionality later than simplify after the fact.

When designing, you should always look for opportunities to collaborate. Don't work in a black box. Be open to feedback. Keep a pulse on how people are actually using your tool. This will provide incredible insights and ideas for improvement.

With that, you can build a very well-designed and easy-to-use tool. When you keep it simple, you’ll drive more signups and generate more revenue for your startup.