jsmorabito
commented
2 months ago moved to Project Handbook/Whitepaper! we can leave in-document comments there
Closed linear[bot] closed 2 months ago
jsmorabito
commented
2 months ago moved to Project Handbook/Whitepaper! we can leave in-document comments there
*last updated 3/25/2024
Introduction
The Obsidian Community Design System project serves two main purposes:
1. It is a documentation project that aims to record the current and most up-to-date UI components of the software for public creative use and to trace design change decisions over time.
2. provide the larger Obsidian community, especially the 3rd party plug-in developers a coherent and comprehensive UI kit supplied with various relevant information (e.g. best UI practices, system default UI patterns, UI specs etc.) so that it will be useful for their creative tool / plug-in building purposes. As a result, whoever uses the community design system will have an easier time creating 3rd party plug-ins or concepts that are in alignment with Obsidian’s pre-established UI patterns to reduce user confusion and potentially ease off 3rd party plug-in’s UX behavior learning curves
*This document should be revised and edited once we have new info or change in direction of objective or action for whatever reason
Objectives
For the designers who will be working on this project, the current main goal is to document and re-create a faithful, responsive, and pixel accurate UI kit that resembles the current running Obsidian software for reasons described above in the introduction section.
Potential Hindrance / Caveat / Food for Thought
- The project of creating a design system is ambitious; at the moment there are only 2 designers (John and Jay) who are actively working on this project. In order to achieve the goal of completing this project within a reasonable timeframe and to keep the momentum going, we need to establish a working methodology.
- The Bus-test: because this project is a volunteering and community based effort, all stages of this project should be 'user-friendly' by itself and filled with sufficient documentation; that is to say if the current designers stopped working on this project, how might the successors still able to pick up where it was left off and continue carrying the mission forward?
- We need to establish an exit-criterial at all stages of this project i.e. to answer the question of when can we move-on to the next step. This should be discussed and established as work begins and keep it as an open dialogue between all project participants.
Actionable Steps
in the following order:
1. To do a thorough survey of identifying all pre-existing components from the smallest UI elements (e.g. a primary button) to more complex compound components (e.g. bars in settings, which contains variations of buttons, toggles, editing fields, various weighted text, description, links, dial, icons, colors, etc.)
a. when completing this part of the project, designers should document learnings, abnormalities, before/after screens, etc.
2. While approaching the second half of step 1, designers should start organize everything discovered by mapping out all UI components in an information architecture map (there should be a few workshop sessions about this step to eliminate designer bias and to examine IA clarity, thus creating a solid foundation for the next steps before moving onto actualizing the UI kit)
3. Start experimenting with re-creating UI from the learnings above and organize them based on the IA map described above, the ultimate goal is to re-create all UI components on Figma
4. actualize all components and correct or adjust things on the go as I expect there will be UI elements or components escaped our notice during the initial survey. Make sure to not lock ourselves up in a corner and always leave room for error and potential adjustments.
Good Practices
1. in order to not get ourselves confused,
a. we need to have a formalized and proceduralized work flow on Linear.
b. to establish a common visual identification language such as a set of icons, pixel measuring tools, and commenting format on Figma, this is for the benefit of knowing the exact specs we are measuring and understanding which step we are at.
2. keen on reporting issues, ideally monthly or bi-monthly check-ins to ensure the progress is still being made.
3. As designers, it’s obligatory for this project itself and its documentation to be user-friendly, especially for passing the ‘Bus-test’ described above.