Simple Design –Talking to people

Whether you’re designing an application for a smartphone or a piece of furniture, it is always with the thought of the user of the product on the other end. You want your product to answer the specific needs of your users, be accessible to them, and allow for a good user experience. But how do you go about this, if your users have somewhat different needs, preferences, and skill sets? monday.com designers Meytal Badichi and Evgeniy Kazenic discuss their idea of simplicity as a guiding line in product design. In short, it boils down to getting to know your users, and how you talk to people.

Getting to know the people

Good communication with people is essentially about understanding what they need, how they feel, and being genuinely curious about the way they see the world. Communication is about relating, listening, and meeting the other at eye level.

What does this have to do with product design? The obvious answer – in order to come up with a solution to a problem, you must first have a good grasp of the problem. What maybe is less obvious, and often lost in the process of design, is the need to design a simple solution, one that is natural and intuitive for the people. This adds another challenge to the design process and requires a deeper understanding of the person on the other side.

The guiding principle for designers at monday.com is the following: a good product needs little or no explanation, which means it’s up to us to make sure that the product is perfectly adapted to the user instead of the other way around.

Product design is like a joke, if it needs an explanation- it probably not working…

Many of us rely on technology to simplify tasks and actions we perform as a matter of routine. The problem with technological solutions is that they often require a degree of technological savvy and know-how for us to fully benefit from them. Roughly 70% of monday.com users are not particularly technologically savvy, and this fact has real implications in terms of how we ultimately view and approach the design process. We’ve come to learn that what constitutes good user experience has a lot to do with the things that appear to our users as familiar; the things that echo their daily lives or resemble the ways in which they naturally communicate their thoughts and their needs.  

Never lose sight of the person you are talking to

To approximate the familiar, you need to be able (and indeed, be willing) to talk to people, and learn to listen to them. But while this principle is, in principle, clear enough, it is easier said than done. Where, then, do the problems begin?

The process of building a product is often long and complicated: once you get a sense of your user’s need, you come up with an idea, for example, an automated function for making repetitive actions more efficient in the system; you then make incremental improvements by way of trial and error, try to distill the internal logic of the feature in order to perfect it. But wait: at one point you suddenly stop, and ask yourself – have I not lost touch with the person for which it was intended? Perhaps you have created the perfect feature, but as it happens, you’ve also created in the process an idealized version of the original user, one which barely resembles the user you’ve set out to help in the first place. The solution is too complicated for the average person to be able to reap the benefits; instead of simplifying their lives by offering them a neat solution to the problem – you have condemned your users to a life of frustration.

“Automatic for the People”

The reference to the classic 1992 R.E.M album (which featured the immortal hit single “Everybody Hurts”) is fitting here in more ways than one. About four years ago, we started to develop a pool of automated features (for the people, i.e., our users), which would, eventually, become one of our most popular and cherished features on the platform. Why automation? Simply because we realized that people were annoyed by having to perform simple actions repeatedly, often several times a day.

And with a few automations they can literally put their work process on autopilot.

The first step, naturally, was to identify these recurring situations, where an automated function would be of benefit to our users. We started with a few basic ones:

Ex. When a status of a task changes to Done, notify my manager/ team member

Ex. When a new item is added, send an SMS to ‘someone’

We reached out to the community and added a request form in our automation center, basically soliciting their requests for automated functions. The response was overwhelming.

Here are some examples of requests/suggestions that we’ve received. Notice carefully, in each of these examples, the precise language in which our users convey their needs. Crucially, this will be the “language” of the product: simple, intuitive, everyday people’s English – no code, no technical mumble-jumble.

“ I need tasks to move to another board when the status changes to stuck”

“ Every Monday at 9am I want all the ‘Done’ tasks to be archived”

“When the task is ‘Done’ I want everyone on my team to know”

At that point, we came up with the idea of creating templates for automation, or as our users like to call them – recipes. Much like the “unseen” text in school, when we were presented with a sentence missing certain words and instructed to fill in the blanks, we decided to generate a template grid that allows the user to simply fill in the blanks. To make it even more simple, we decided to generate a limited amount of templates, which in terms of coding, “behind the scenes”, stood for an enormous amount of possibilities.

In the image, there’s a classic exercise of filling in the blanks. We used this model to develop a template grid to generate automations.

We closely examined the ways in which people communicated their needs to us, the words and sentence structures used to describe a certain automated function, and how they understood the function itself, etc.

• When __________ changes to ____________, move task to ____________
• When a new task is created, send an email to _____________
• Every _______ at ____, archive tasks marked as ____________
• When date arrives, and _______ is not ________, notify ____________

Within a year, our automation center was virtually exploding, with over 100 services to choose from; a bit like a plug-in store for your browser, but specifically designed to help our users perform specific tasks most relevant to them. But with more and more requests for automatized functions flowing into the system, it became difficult at some point to navigate the system and to find exactly what one was searching after. We needed another solution to make the automation center more accessible and convenient.

We then decided to break down all the recurring elements of our users’ natural language into even smaller units and use those elements as building blocks for creating one’s own automation based on pre-programmed templates. To create a certain valid automation, the user had to choose a ‘trigger’– something that will start the automation, and subsequently an ‘action’ to perform after.

This model, which encouraged our users to customize their own set of automations by mixing and matching between different options, would allow us to significantly shrink the automation center to include only a few basic options (understand it first, build it after).

The new sentence/automation building feature was a smash hit. Why do you ask? Because at the end of the day “everybody hurts”, and because everybody likes simple solutions. Ours, in this case, remained true to the original logic, which was to help our users by means most familiar to them – using their own language. Mix and match, write your own code without knowing anything about programming – and without needing us to do it for you: that’s when things became especially fun & customizable! 

It took a while, to be sure, but we got to know our users better and better in the process. This is the nature of intimacy, and that is simply how communication generally works: the longer the relationship, the finer the tuning.

The most important thing we learned was to let our own logic be determined by our users,

rather than dictate or force our ideas on them.

In the end, we designed a product that was a result of our engagement with people and our observation of how they do things in their real lives.