Design
Thank you for your interest in designing UX and/or UI for Manyverse! Follow this guide to understand how we do design and how to get started.
We use Zulip for structured chat, so make sure you make an account there and familiarize yourself with it.
1 Read the guidelines
So far we are light on our design spec, which at the moment only includes Principles and themes, which are the most important to give design a direction.
Another relevant resource to read is our Starchart defining areas that we are focusing on in the present, and areas we will focus on in the future.
2 Familiarize yourself
Get to know the Manyverse app as a user. Make sure you install it on your main device, create an account, and connect to other people. Take a careful look at how navigation works, and how each screen is laid out on mobile and desktop.
As an open source project running low on budget and resources, we cannot afford full "redesigns". Your work will thus consist in discovering, suggesting, and mapping small changes that will improve the app. This is not so common for designers, but we have tried different design processes and the micro-iterative process has been the best.
3 Join our chat
Given our iterative design process, it is important to have quick feedback cycles and co-designing with us. Join our Zulip. We have a dedicated design
stream there, under which there can be many topics.
4 Start a conversation
You may find and comment issues on GitLab (see the developer contributor guide) that are in a state that require UX/UI design. It's also perfectly fine to just start a conversation in Zulip.
Our design process is a conversation. Wireframes (low definition or high definition) are just artifacts in a discussion so they should not be prescriptive and final. We don't recommend spending hours/days in Figma, getting it all perfect, and then submitting to us for development. Instead, spend a few minutes sketching an improvement suggestion, show it to us, and allow the conversation to evolve. We may also contribute back with other sketches.
This is also the place to discuss other design needs and how to solve them, like UX research, usage analytics, project goals, and others.
5 Document conclusions
Once we reach a conclusion in this iterative design conversation, we typically want to document that and make it ready for development to begin. For this, you will create an issue (or edit an existing one) on GitLab that documents the design changes.
In this phase, it's important to consider all corner cases associated with your proposal, such as:
- Extreme states: how does it look like when there is no content? When there is a lot of content?
- Theme breakpoint: how does it look like in dark theme versus light theme?
- Screen breakpoint: how does it look like on mobile versus desktop?
- Input breakpoint: how are mouse (desktop) affordances versus touch (mobile) affordances?
- Accessibility: keyboard-only navigation, low vision (contrast), low color recognition
- Translation: text fields may look fine in English, but is there enough space for longer words in other languages?
Our goal is to come up with a simple and actionable plan that developers can easily put into production.
Thank you for your time!
This file comes from our Wiki page on GitLab. Last updated on 2024-11-21.