We started Monolist after years of spending too much time managing our work, and not enough time doing our work. We felt the pain of working across too many tools, and letting too much slip through the cracks. So we wanted to do something about it.

But we had absolutely no design experience. After a year of slogging through thousands of iterations, we wanted to share some of the lessons we’ve learned on how to design without any formal training.

When I was in school, sometimes I would study for finals by looking at the answers to practice exam problems, and reverse-engineer an approach for getting to those answers. I usually failed exams when I studied like that. Designing a product isn’t so different.

In design, just like exam prep, finding answers is pretty easy (cough…Dribbble…cough), but you probably won’t learn anything if you rely on them. The hard part is understanding the problem you’re trying to solve, and getting to the answer yourself.

Most of design has nothing to do with what is on the screen.

When developing a product, you form a hypothesis about a problem that a specific person has, and you build something as quickly as you can that you think solves it. If the problem is big enough for that person, and the product you’re building solves it, they’ll probably buy it.

Simply put, design is the process of identifying and solving problems. And just like with that tricky derivative on your college calculus exam, there are rules, tools, and assumptions you can rely on to get to the answer without looking at the key.

Before you have a solution, you must have a problem, and someone who suffers that problem. Is the problem you have a hypothesis on one that your customer experiences? How does that problem make them feel? Is it important to them? Do they currently have any way to solve it? What is that solution, and where does it fall short?

From these conversations, you should come out with crystal clear understanding of what problem you’re solving, the particular customer profile you are solving for (hopefully you even know his/her name), and a hypothesis about the solution.

First principles are basic truths or assumptions that we can use to develop reasonable arguments. First principles thinking (also known as reasoning from first principles) is a way to use these assumptions in order to break down monolithic or complex problems into many smaller, more solvable problems. Solve all the small ones, and the big one goes away.

When you have written down your customer’s problem:

1. Decompose it into as many elements as possible.
2. Enumerate your assumptions and principles about the solutions to all of the constituent problems.
3. Identify which of the constituent problems are most solvable based on what you know is true.
4. Come up with something from scratch that solves the problem, using the principles and beliefs as a north star for governing the solution. If your existing design patterns aren’t aligned with your principles and don’t solve the problem, introduce a new pattern. Don’t let the tail wag the dog.
5. If you finish the iteration, but it is not an accurate reflection of your principles, try again.

Let’s explore an example that’s close to home for us: how to make it easier to discover tasks in the inbox.

First, let’s explore the problem: Important tasks get buried in the inboxes of engineers

Now let’s decompose this problem, and see what we can solve.

(Element 1) Engineers use too many tools which send too many emails

Engineers receive important emails from the tools they use, but those notifications tend to flood their inboxes. The most important thing is the service that’s sending the notification, and the recency of that notification (if it’s important, you might need to respond quickly). As such, we decided to condense all notifications from individual services into stacks, which move around in the inbox like other emails, but represent bundles of notifications instead of just one email. In our solution, it’s paramount that you can quickly scan to see what service is sending the notification, and when the most recent update was relative to your other services.

(Element 2) Engineers receive many emails from senders they never engage with, and (Element 3) Engineers receive emails from senders they don’t want in the first place

People go to their inboxes to find out what has changed that might affect how they want to spend their time at work. However, engineers are bombarded with emails from recruiters, sales people, or tools they don’t want in their inboxes, so this process is not always productive. We wanted to make it easy to remove these unhelpful messages from the inbox, while maintaining the ability for the user to see everything that changed since they last checked the inbox. As such, we landed on treating new senders as “friend requests” within the inbox. You can see all the content of the message you’ve been sent, but the primary choice the user faces is not how to deal with the message itself, but how to deal with the sender of the message. If the new user is unwanted, you ignore them once and never receive messages again.

(Element 4) Inboxes treat tasks the same as other emails in the inbox

Inboxes are naive. They simply collect notifications and messages that other tools and people send you. However, not all messages are the same to the end-user. If you’re trying to discover new work, you want to immediately understand what new tasks you have, the current status of that task, and any new information related to that task. So we decided to pull all of that information together for each task that you have, whether it’s a ticket from a project management tool, or a pull request that needs to be merged.

Breaking down our problem to its most basic elements helped us design solutions with confidence that solve the broader issue of discovering tasks in your inbox.

When designing in a collaborative environment, disagreement can be productive and healthy. If not handled correctly, disagreement can lead to heated discussions and spur resentment.

At Monolist, we rely on a few operating procedures to promote healthy discourse that pushes our design forward, and keeps us happy to be in the same room.

1. All specs (product and design) must have governing principles that are agreed-upon before work starts on the project.
2. Before design reviews, we review the problem governing principles.
3. When providing design feedback, tie it to the problem, the solution, or the underlying principles. These concepts are not only valuable in building robust solutions to problems, they are also a great vocabulary to provide feedback.
4. Before you raise an issue, take the time to consider an alternative to propose.

To be successful as a startup, you face stark constraints. You have limited runway, and need to solve a big problem. That means you need to build quickly, without over-investing cycles in anything that won’t get you to product-market fit. As such, selecting tools that will increase your pace of development is crucial.

At Monolist, we’re obsessed with Figma, because it:

1. Inherently promotes collaboration and transparency
2. Allows us to sell before we build
3. Makes design delightful

Collaboration

At Monolist, we’re all designers. Figma’s group editing makes it seamless for us to review and comment on each-other’s work, as well as maintain an open and transparent design library for anyone to view.

Prototyping with ease

Building software takes time. Making designs in Figma is faster. When we have a new idea, we use Figma prototypes to explore solutions and show them to customers in days instead of weeks.

If you understand the problem you’re solving (by talking to your customers), you’ve articulated and written down your governing product and design principles, and you’ve chosen the right tool, the pixels will most likely sort themselves out.

We still have a long way to go, but I’m proud of what we’ve learned in our first year of designing Monolist, and how much we’ve developed as designers.

If you’d like to provide feedback on what we’ve designed so far, try out Monolist.