ebugden
commented
3 years ago The issue description frames these guidelines as mainly layout and graphic design principles. Discussing that level of high-polish this early in the design process doesn't seem super relevant.
Instead, these guidelines could be reframed as more generally applicable "design guidelines". These guidelines would be a framework of principles to structure and streamline the design process (ex. facilitate feature prioritization).
Below are some ideas for content that could be included.
Design philosophy
We aim to build a tool:
- Designed with intention: Decisions are thought out and choices can be justified.
- Using a collaborative process: Through periodic consultation and review by analysis experts, as well as user feedback, this tool aims to reflect the knowledge and experience of the analysis community.
Guiding principles
Thoughts to keep in mind when designing. Quick sanity checks that lay the foundations for the project’s design culture.
Note: These principles can be broken if appropriate, but it’s important that any breaking is an intentional (and justifiable) decision.
Build using existing UI conventions.
By not reinventing the wheel, the UI remains consistent with user expectations. Other benefits:
- Uses existing user knowledge, reflexes, and intuition
- Contributes to a sensation of comfort, familiarity for the user
- Builds user confidence
Examples of UI conventions:
- Ctrl+Z to undo
- Click and hold to initiate drag and drop
- On mobile, scroll up to refresh
Conventions depend on context. For example, the standard position of window options is different on Windows and iOS.
iOS:
Windows:
Build based on the user’s goals.
Ask yourself: Who is the user? What are they trying to accomplish? Be aware that a user’s needs vary depending on their profile (ex. First time trying the tool vs. Experienced user). Benefits:
- Provides concrete high-level goals that orient the design process
- Provides references for prioritization of features during development
See “Feature prioritization & development” below for more details.
The more important the information, the more it should stand out.
And lower priority information should stand out less. Ex. Do order table items by importance, but don’t use thick black gridlines.
Shield users from unnecessary complexity.
Overview first, details later. Increase complexity only when necessary (or when explicitly requested by the user). Benefits:
- Avoids intimidating, overwhelming, or distracting the user
- Helps build user confidence (gradual learning curve) Consequences:
- May reduce discoverability of certain powerful features
Feature prioritization & development: Who is this feature for?
Thinking about who a feature is for can help with:
- Feature prioritization: When choosing which feature to develop next, ask yourself “Does this feature help the target users?”
- Feature development: During development, keep in mind the target user’s goals and experience.
Users can be divided into four groups based on their level of investment in the tool:
- First contact
- First try
- User
- Contributor, Developer
Each of these four stages can be characterized by different:
- Questions the user is exploring (different goals)
- Activities the user performs with the tool
Also keep in mind:
- Each stage requires that users have some additional knowledge (ex. Technical terms, techniques).
- User’s tolerance (for learning, for complexity, for issues, etc.) will start low when they first encounter the tool and will increase as their trust for the tool grows and they become more invested.
CC: @ssmagula
Create a document with style principles that apply to the whole project or several component types (ex. General layout principles, colour palette, UI component semantics).
Prerequisite: Create chart style guidelines #152 before diving into defining these more abstract guidelines.
Inspiration
Style guidelines can be strongly inspired by the VS Code and Grafana style either by:
If reverse engineering guidelines, the tag colours in the Grafana live demo dashboard management could be a good place to get an idea of the colour palette used:
Content
Style guidelines could be structured as:
Include good and bad examples to illustrate the principles. Example pictures are often best (rather than text explanations).
Could also include subjective or human checks (ex. Does it feel visually intimidating? Do you feel invited to explore?). High-level user-focused questions can act as sanity checks. They can help avoid tunnel vision by encouraging devs to think about the project from a different perspective.