Improving the Meshtastic app UX

[matthiasdebaat]

Hi everyone 👋

I’m a UX designer at the Open Home Foundation, where I work on Home Assistant. Recently, I had the pleasure of meeting some of the Meshtastic developers at The Things Conference, and that conversation inspired me to get involved.

I started experimenting with a T1000-e node and quickly became excited about the potential of this project. I’d love to contribute by helping improve the user experience of the Meshtastic app. Earlier, I started a discussion to better understand some of the current design decisions, thank you for the replies there.

Understanding the users

The current app seems to have been built primarily for users interested in antenna technology, such as Outdoor Adventurers and Preparedness Communities. For many, Meshtastic is both a tool and a hobby: they enjoy exploring range, tuning antennas, and experimenting with configurations.

At The Things Conference, I was shown a demo case with nodes designed for First Responders. I think this is a really exciting opportunity for Meshtastic, but this user group has very different needs. They want nodes that are simple to use, with reliable communication and minimal complexity. Many of the advanced features that enthusiasts love might actually get in their way.
These two user groups (enthusiasts and professionals) have almost opposite expectations from the same product. I believe there’s a way to serve both, and I’ve been exploring a design approach that could make this possible.

Next Steps

I’ve created a redesign of the iOS app (though most ideas apply to Android as well). In the comments below, I’ll share specific design ideas that aim to:

• Improve the overall UX
• Make the app easier and more reliable for First Responders
• While still empowering Outdoor Adventurers and Preparedness Communities

Some of my ideas might be technically challenging or not fully aligned with the current Meshtastic vision, which is exactly why I’m starting this discussion. To gather feedback before creating any concrete issues or proposals.

Looking forward to your thoughts and collaboration!

[matthiasdebaat]

Clarifying the navigation

Before diving into the navigation itself, I want to briefly touch on some Meshtastic terminology, especially the concepts of nodes and users and how they relate. Each node represents a user, but users may also manage or connect to multiple nodes. This relationship is powerful, but not always clearly reflected in the current app structure.

Based on this, I explored a new navigation model that makes these concepts easier to understand and navigate.

The new structure introduces four main tabs:

• Chats: A familiar overview of direct messages and channels, similar to the current app.
• Contacts: A redesigned version of the current Nodes tab, showing other nodes in the mesh (excluding your own).
• Map: Equivalent to the current Mesh Map, providing a visual overview of the network.
• My Node: A combination of the current Settings and your own node from the Nodes tab.

Above these sits a new umbrella section called My Nodes, replacing the current Connect tab. This view lists all paired and discovered nodes. When you select a node, you “enter” that node’s environment. From any screen within that context, you can navigate back to My Nodes using the back arrow. On larger screens, instead of a back button, you will have a sidebar of My nodes.

The goal of this structure is to clarify the core concept of Meshtastic, what a node is, what you can do with it, and how to manage and configure it. While keeping navigation simple and consistent.

[matthiasdebaat]

A GIF to show it in action

[matthiasdebaat]

Guiding the user when connecting a node

At the moment, new users don’t get much guidance when connecting their first node. They’re immediately presented with a lot of technical information, such as selecting the LoRa region and are shown detailed explanations about what LoRa is. For beginners, this can feel overwhelming and confusing.

My idea is to create a more guided and focused onboarding flow that helps users connect their node with fewer steps and less friction.

For example:

• The app could automatically select the first available node when one is found.
• It could show an image of the detected node type, making it more tangible.
• The user could then assign a friendly name to their node.
• The LoRa region could be pre-selected based on location, and simply confirmed by the user instead of manually chosen.

This approach would make the connection process faster, more intuitive, and less technical, while still allowing advanced users to adjust settings later if they want to.

[matthiasdebaat]

A GIF to show it in action

[matthiasdebaat]

Also made a design for the "manual add" flow. Curious what you think about this!

[Tema-man]

That's approach is really great!👏 Great job!

1. I'd also like to discuss "Offline" access to the chats. Now, at least on android, if user is disconnected from node, they are still able to see last Chats history. Can we bring it here as well? The other screens: "map", "nodes", "settings" etc are there as well, but locked, which is kinda confusing from user perspective as for me (there are a lot of options to see, but none of them a clickable :) without connection to the LoRa )
2. The "change" button for short node name looks a bit confusing. IMHO it's a bit clearer to have two text-field for both names on that screen. WDYT?

[matthiasdebaat]

Now, at least on android, if user is disconnected from node, they are still able to see last Chats history. Can we bring it here as well? The other screens: "map", "nodes", "settings" etc are there as well, but locked, which is kinda confusing from user perspective as for me (there are a lot of options to see, but none of them a clickable :) without connection to the LoRa )

That would be great! Is this data stored on the phone or on the node?

[matthiasdebaat]

The "change" button for short node name looks a bit confusing. IMHO it's a bit clearer to have two text-field for both names on that screen. WDYT?

Idea is to make it clear what you change, in this case its the circle content. For me as new user, it was not clear from the start what short and long name was. I've used the same design pattern on the onboarding, as I have on the user settings of "My node".

[matthiasdebaat]

Improving the chat experience

This idea focuses on the Chats tab and how users start conversations. The goal is to make this experience feel more familiar, closer to popular messaging apps like Signal or WhatsApp, while keeping the unique power of the Meshtastic network.

• The new Chats tab would show a single list of all conversations, including both Direct messages and Group chats (previously called Channels).
• I suggest renaming channels to group chats, since this term is more intuitive and widely understood, especially for less technical users.
• In the chat list, users can still tell the difference between DMs and group chats. For example, DMs could show a short name, while group chats might display the channel number.
• Unlike the current Messages tab, where DMs are automatically created for all discovered nodes, users would now start a chat manually, then select a contact or node to message. This aligns with how most messaging apps work and reduces clutter for new users.
• Currently, group chats must be created through the Settings menu, which is disconnected from where conversations actually happen. I propose moving this action directly into the Chats tab, making it easier and more natural to create new group chats.
• Once a group chat is created, inviting others can be tricky. Fortunately, the app already includes a useful sharing feature in Settings. This same functionality could be reused here, allowing users to share a specific group chat via QR code or link right after creating it.

This redesign would make chatting on Meshtastic simpler, more familiar, and easier to adopt. Especially for new users, while keeping all current capabilities for advanced ones.

[matthiasdebaat]

This is an interesting conflict between "Make the app easier and more reliable for First Responders" and "Empowering Outdoor Adventurers and Preparedness Communities"

To get a better understanding:

• What is the goal of a technical message channel?
• Can a channel used for group communication and technical messages (e.g. location, node info) at the same time?
• Can these be identified and show different?

[AndrewLemons]

• The purpose of a "technical message" channel is to transmit non-human-readable data such as location, telemetry, and node information across the mesh. By default, this type of information is sent on a node's "primary channel" (channel index 0).
• A single channel can absolutely be used for both group communications (like text messages) and technical messages (such as location updates). In fact, all messages, whether they're user chats or node data, are sent over the channel(s) to which the node is subscribed. There is no separation at the channel level; both types of messages can coexist on the same channel.
• Because of this design, it is not possible to dedicate a channel exclusively to "technical messages" or to distinguish between technical and group messages at the protocol level within a channel. All traffic on a channel is received by any node in its channel list, and the messages are interpreted or displayed based on their type by the receiving app or device. For example, the current apps will often label or sort message types (e.g., separating out location packets versus chat), but the underlying protocol does not treat them separately.

For a real-world example: On my nodes, the primary channel (channel 0) is configured as my family's private channel. All my family's nodes send/receive location updates and node info on this channel. Occasionally, we chat via text here as well. Separately, I have channel 1 set to "MediumFast", which is the typically the "default" primary channel for my area. If another node has "MediumFast" as their primary channel, their device will send location updates and info there, and I will receive those packets. My nodes, however, will only receive those packets and never transmit location or node info there since it is not configured as my primary channel.

A good reference.

[safwat-halaby]

Some of those "technical" messages are actually useful to non technical users, for example: the position of the other nodes and their battery levels and how strong their signal is. This can be leveraged to retaining the "group chat" language for non technical users: The user can mark only a single "primary group chat".

Maybe they're shown the following explanation: "Your device will periodically broadcast useful information such as battery level, location (if allowed) and other technical information to users on the primary group. Users in the primary group are also more likely to detect whether or not you're online. You can only have one primary group."

Behind the scenes, the group selected as the "primary group" is put in index 0.

Now, here's a challenge to the "group chat" terminology: Essentially, any one can join the public channel because its encryption key is trivial. This is not so expected for what users typically expect of a "group", but this is exactly what users expect of a "channel" (think Telegram channels). So, a UX-friendly approach could be as follows: Channel with a private key => "group", channel with a trivial key => "channel", or possibly "public group".

So, a user with a newly installed Meshtstatic would find a single "channel/public group" (the default public channel which has a trivial key) which is marked as the "primary group". They can create "group chats" (encrypted private channels) and mark one of them as the primary group. In this scheme, I don't think the UI should present a "channel creation" option. Leave this for some advanced menu where a tech savvy user can specify the channel key manually; perhaps they go through the normal "create group" flow, then modify the channel key in the group settings. But if any "group" has a trivial key, then it is shown as a "channel/public group" in the list.

EDIT: The periodic location telemetry can optionally be sent to a channel other than the primary group (but it's never periodically sent to more than one channel), this requires taking into account too. So ONE channel can be the primary channel, and ONE channel can be the "periodic location advertising channel", and they're usually but not necessarily the same one.

[safwat-halaby]

A very interesting UX challenge is the fact that you cannot communicate with another user privately if you do not share any common channels. (Open question: Can you privately communicate with users who aren't on the same primary as you are?)

[victordomingos]

I find this design proposal very appealing. Great job!

Regarding the Chat/Channels discussion, as a user I feel that it would be nice to have Channels and DMs separated in the bottom tab bar. Since the Connect tab will be merged with the Settings, there is space to place two shortcuts there instead of a single one.

I also think that "Channels" is a more correct term than "Group Chat" because since communications are mostly based on radio, there are times where we receive messages that are replies to other recent messages we didn't receive. For instance, node A sees node B, node C sees node B, node B sees both, but A and C don't see each other. Every time B is replying to a message from C, node A will read those replies as if they were to "empty messages". In the context of a radio channel it makes some sense. In the context of a group chat it is confusing because not everyone receives the same messages.

[matthiasdebaat]

Rethinking the Contacts tab

The Contacts tab is a redesigned version of the current Nodes tab. It shows all other nodes in your mesh, excluding your own.

The idea behind Contacts is to make the concept feel more personal and human-centered than Nodes. Each contact would have its own Contact Info page, providing quick access to:

• Encryption settings
• Direct messages
• Shared group chats
• Node location on the map
• Weather data
• Node details
• Logs

Finally, I added a feature to personalize contacts. Users could add a nickname and personal notes for known contacts — stored locally on their own device.

This small addition helps make the mesh feel more social, understandable, and meaningful — especially for users who interact with multiple people or teams through Meshtastic.

[matthiasdebaat]

A GIF to show it in action

[matthiasdebaat]

Contact with less information

[victordomingos]

In the current app UI, something that bothers me is the fact that, to check a trace route for a node, we tap Trace Route in one section, and then we need to scroll to another section to review the logs. Not very intuitive, could also be improved.

[pedjas]

Great work and proper UX design of application interface.

I believe this would not be applied to Meshtastic app simply because it is more like all around configuration app. But this could work excellently as separate messaging app.

Few notes:

There are actually no users on a node. You cannot have more users on a node like separate accounts. Short an long name are actually node's short and node's long name.

It is bit confusing as node is identified by Node ID (which is factory set and cannot be edited), and short and long name. All three are inconsistently used within application and protocol, and to add complexity, Node Id is sometimes represented as plain integer decimal number, and sometimes as hexadecimal number, and for practicality, most often last four hex number of a node ID are used. They really did good job of making it complicated. :)

It is good to have all three on page that allows changing short and long name for a node, and it should be named Node info or something like that instead of User.

For contacts page there is also something important: Meshtastic does not have contacts per se. It has list of heard nodes. To make it complex, that lists updates with new nodes and older nodes (not heard for some time) are removed. User also has option to clear node list totally and loose all nodes information. So you cannot rely on using node list as contacts list.

However, there is need to have Contact list in classic manner - list of contacts that is independent of age and with possibility for user to add some custom information for each contact, group them, etc... It is also good to distinguish my nodes, favorite nodes and other nodes, maybe even allow user to create custom grouping for nodes. Contact list should stay preserved even if node list is erased.

About message channels. They could and should be treated as topics. It becomes bit complex as each node can have differently set channels so you must have it in mind. It is not that all nodes share all channels. Node may share some channels with one group of nodes and other channels with other group of nodes but each node can have up' to eight channels.

Messages in channels can be distinguished by message type. There are several types of messages and it is probable that more types would be added in future. It would be good to have messages in one channel separated by type.

[safwat-halaby]

I think the "node list" maps very unnaturally to the user-familiar "contacts list" because of the reasons mentioned by @pedjas .

However, Meshtastic supports "favorite nodes". And these map very very neatly to a "contact list".

Essentially, the node list is dynamic and depends on node discovery. Currently, metastatic allows favoriting some nodes and then they never leave that list.

On a user-friendly UI, this can be displayed as two separate lists:

• current node list becomes "discovered nodes" or "contact discovery" - a list of semi-random nodes that slowly populates and sometimes depopulates.
• Favorite nodes becomes a separate "contacts" list, or maybe "favorite contacts" to retain terminology with the documentation. These are nodes selected from the "discovered nodes" list, and it's a permanent list just as a user expects from a contacts list.

[matthiasdebaat]

Rethinking “My Node” and settings

The My Node tab combines your personal device information and settings. In the current app, many of these settings are grouped by their technical modules, which can make navigation overwhelming and difficult to understand. Especially for users who aren’t familiar with the underlying hardware or protocols.

In my redesign, I’ve reshuffled and regrouped many of these features to make the structure more intuitive. Advanced modules and configuration options are still available, but less prominent. The idea is to simplify the interface and make it layered in complexity, so new users see only what they need, while advanced users can still dive deeper when necessary.

I also propose highlighting the most important aspects of the device by breaking out key areas (such as Role and hardware configurations) into their own dedicated pages.

The new My Node overview includes these main menu items:

• User
• Node info
• Role
• Location tracking
• Weather conditions
• Notifications
• LoRa
• Bluetooth
• Network
• MQTT
• Power
• Buttons
• Display and LED
• Units and time
• Security keys
• Firmware update
• Reset
• Reboot
• Power off

Below that, there’s an Advanced Modules group, containing:

• Serial
• Detection sensor
• Store and forward
• Canned messages
• Range test

This approach makes the app feel cleaner, more structured, and easier to explore. Without removing any of the flexibility that makes Meshtastic so powerful.

[matthiasdebaat]

A GIF to show it in action

[Sabering1]

It might be more efficient to relocate the node settings to the top right or left corner. When positioned in the bottom row, the settings occupy valuable space that could either remain clear for a simpler three tab layout or be repurposed for other functions. Once the node is configured, the settings section serves little ongoing purpose, and its current placement contributes to unnecessary visual clutter.

[garthvh]

These are grouped together because they are sent as single messages both locally and for remote admin.