Actions for ginlo

Product Design

At Brabbler, one of the key questions we grappled with was how to enhance the chat experience. We had a solid concept in place and had already completed the initial testing phase, with development work underway, when the company eventually had to cease operations. The presented designs were all my own, even though such concepts are always the result of teamwork. Collaboration and collective brainstorming are key to refining any idea and bringing it to fruition.

Problem & Hypothesis

Messaging apps such as WhatsApp, Telegram, and Threema have proven to be highly effective means of communication. What's the reason to make a new one, then?

At Brabbler, big topics were security and privacy, but we focused in addition to enhancing communication efficiency and accessibility. We understood that users have different communication needs, and therefore, we aimed to standardize specific use cases to make our app more user-friendly and usable. Our goal is to provide a platform that not only ensures security and privacy, but also improves the overall communication experience for our users.

Process & Results

The first step in addressing this issue was to deconstruct what digital communication is and why we use it. The following image gives you a small glimpse into this process:

As a result of this question, we ended up with a three-step approach:

Actions, the short-term step

The first step and groundwork for what should follow would have been to enhance conversations with the ability to handle specific situations with a given solution instead of a message. We called them “Actions” and they were already in development and therefore had a finished design concept.

Example: Polls

If you need to find a date for a meeting you do not just have the option to post the question for the date as a message, but you can also open a poll. The advantage of the latter is that the conversation is not fluted by the clutter of the responses to this particular question and that the answers will be summarized automatically.

A simple poll is pretty easy and straightforward if you think about it. It could work like this:

Planned Actions

In addition to polls, we planned to have events, checklists, and reminders. This selection should suit most use cases.

• With events, we could give users the possibility to handle them within a group of people cumulatively without everyone having to use the same calendar - we could maintain a ginlo calendar integration that keeps everything together.
• Checklists would be a great way to maintain common lists of tasks within a group - e.g. a grocery list.
• And finally, reminders were just a reduced version of events, with just a single point in time, but would allow again to reduce clutter because you don't need to have a full event just to inform the group about an important point in time.

Action Wrapper

To keep actions usable, we needed a generic way to handle actions. Therefore, we designed a generic wrapper that would fit a broad range of use cases.

Integrations

Of course you need a way to access actions - otherwise, they would help nobody. They are part of a conversation so they are displayed here. But actions contain the most of the time some data which keeps them relevant for some time - therefore you would be able to access them also via the conversation detail panel and via a new tab in the overview screen of the app.

Interconnected actions, the midterm step

Actions in themself were not a great innovation - concepts like this are already introduced to Telegram, Apples Messenger, Skype, and some others. Where this whole concept becomes interesting is when you think of actions not as dedicated entities but as an interconnected system - e.g. if you could create the event right out of the poll in the circumstance a group has committed itself to one slot in time and don't need to start by zero.

And we can think this much further - what if we can also attach actions to each other? E.g. a checklist that offers a list of who has to bring which item to the grill party in the event.

One of the most common reasons to invite people to groups are events - e.g. birthday parties. Therefore, we could understand actions, in this particular case events, as something which can not only exist inside a conversation but also stand on its own and which can contain conversations in themselves. So the user would be able to create an event and invite all the wished participants directly. If a recipient of the invitation declines it, he could be automatically removed from the conversation. The details of the event could be presented more prominent than just being the first message and if there are adjustments to the event itself they don't end up as just another message everybody has to handle by himself - but could be implemented directly with the wrapping information. Of course also in this scenario, it makes sense to have the possibility to attach actions to actions. Where the possibility, to have actions dispatched from a conversation, would also come in handy would be self-management.

Vision, the long-term step

But also, the concept of interconnected actions is limited in its potential. It makes just use of the concepts of digital communication we already use in our everyday life. But is there a way to be even more efficient?

We recognized the importance of understanding the user and their needs. While standardized actions were a useful starting point, we wanted to give users the freedom to express themselves however they saw fit. We recognized that language was a powerful tool for this, but traditional text-based communication was still not efficient enough.

A reasonable possibility is to use the standardized data in our actions and build visual stories out of them, including every change and all related responses by all participants.

Images can describe complex contexts much quicker than text. They can add dimensions of information that text simply cannot convey, such as emotions, colors, and shapes. As such, we explored the possibility of using standardized data to build visual stories, including every change and all related responses by all participants.

The next step would be to understand the user and what he wants to do, therefore loosening the defined possibilities a user has with the given actions. The user should be free to express whatever he needs and wants - also as an interactive conversation element. We have something which we use for use cases like this, language. But language is transported through text, and text is still not efficient. So to address this, we explored the possibility of interpreting the language that users were already using, using machine learning to create more intuitive and efficient communication tools. While this may still be some years away, we saw this as a promising avenue for future development. By continuing to push the boundaries of digital communication, we believe that we could have created more efficient, effective, and enjoyable communication experiences for users.

Felix Kalkuhl © 2025 — Imprint (German)