If you are designing a new component for Clarity or enhancing an existing component, please follow this step-by-step process in order to streamline the design, documentation and review phases of this process. We will work together with you on during each of these phases to guide you through our process.
sing markdown the UX and Visual Design can be documented directly in a github issue. Please create a Contribution proposal,if there is not an existing issue related to the proposal. There are three phases a design goes through as it's refined and made ready for development.
UX research includes looking at the problems this component will solve. Identifying pre-existing solutions and the feature sets that should be included as part of a Clarity component. Usually answering the following questions will get you started
Try answering the following questions to get started on researching and documenting the findings for conseration:
- What problems does this component solve?
- How will users interact with it?
- What is the primary or base use case for this component?
- Are there features that would enable less common but more enhanced use cases?
When you write up the proposal, start by describing what the component does as well as anything known thats used today to solve the issue. Then list the use cases that can be paired with distinct visual designs.
As the design evolves we will separate use cases into two lists. The first list should be the use cases necessary for
delivering an MVP version of the component when it gets developed. FOr a variety of reasons, some use cases may
not be necessary for MVP. These secondary use cases should be moved to a list of *Future Use Cases**. For
practical reasons, visual design should not need to be addressed for these use cases at this time. It is preferable to
identify and focus on only the use cases needed to implement the MVP of a new component. Future use cases should be
handled with a separate Design proposal that builds on top of the initial work.
Again finding the answers to questions is usually the best way to get started.
- What are the existing solutions used in other applications/component libraries/mediums (native mobile/ video/ television etc)?
- How has this problem already been solved:
- In the past with older, less digital technologies?
- Today, with modern digital tools?
- Are there variations or features that may not be a good fit for Clarity?
Obviously, we are looking for a representational cross-section here and not a doctoral thesis. :) Answers to questions like these (please feel free to add your own) will form the foundation of the documentation that will be recoded on github. Please use the github issue and markdown to organize and document this research (links, names of products, design systems and screen shots and use cases) as part of the UX research. If you are unfamiliar with markdown, please reach out so we can help guide the organization of your research.
Once all of the use cases that need to be developed have been identified, they need to be paired up with visual designs focused on the details for each use case. These visual designs can be created using Sketch.
A good place to get started is with the Clarity Design Resources:
- [Clarity Light Theme](https://github.com/vmware/clarity-assets/raw/master/sketch/light/clarity-library-light-1.0.0 .sketch)
- [Clarity Dark Theme](https://github.com/vmware/clarity-assets/raw/master/sketch/dark/clarity-library-dark-1.0.0 .sketch)
- Clarity Icons
Download those files and familiarize yourself with how the existing components are organized. Reach out to us if you have questions about the natural place for a new component. Much of the visual aspects for the new component has already been built into the sketch files (typography, colors, padding, font-size etc). What you have to do is find an appropriate place to create the visual representation of the proposed component. This asset will be used to generate mockup images that will be useful when:
- Documenting use cases and their respective features
- Creating dynamic mockups (with a tool like InDesign) as needed to demonstrate aspects of a use case
Finally, the sketch file will become the design representation of the component and stay part of the Clarity Design Resources once the component is built in code.
Remember, if (for example) a component has five use cases and ten features you still only need one instance designed in sketch (there is a handy way to toggle visibility for various parts of a sketch document). This is how we suggest that multiple visual representations be created for documentating the various use cases on github.
These resources serve two purposes. First, they establish the visual language that a Clarity component should have (color vertical rhythm, typography etc). And second, they provide a natural place for the component design to be integrated into. This second purpose is important. It is from these files that the implementation details of the component will be documented as well as made available to other designers building Clarity applications once the component is released for production use.
For more dynamic features sketch files can be used in a tool like InDesign to create functional mockups.
Images from the sketch files and/or links to the InDesign mockups can then be paired with the details for each use case and documented on the github issue so the information is public and available to the community.
When creating the visual design for each use case keep the following in mind and make sure the proposal can accommodate a generalized solution that factors the following in (as appropriate):
- internationalization
- long/short values
- error/zero/empty states
- accessibility
- responsive
- touch
- edge cases
- motion
Design review is a process of refining the use cases, the visual look and feel and discussing the dynamic behaviors for each of the use cases. Through this discussion the desired features can be documented in the issue and preserved for future. Most of the time this conversation can happen on the github issue itself but for more advanced components we can set up a private slack channel and or video conferences for regular, live design review sessions.
Share solution progress with Clarity team to make sure it aligns. We will engage on github and set up more collaborative review sessions as needed for the length of the process. Usual feedback that can be expected will include things like:
- When more information is needed on the design or use case
- When the design is needs more refinement feedback will be targeted to specific elements of the design
- When there are missing considerations that need to be accounted for
Clarity has very high standards and even more stringent accessibility requirements. During this phase please, please, please do not take the feedback personally. It can and should be directed at the design, the feature or the use case. During review sessions or via github comments, the feedback in no way is intended as a judgement of the designer or the important work they are contributing to Clarity. We recognize how difficult it is to contribute meaningful work to a project with high standards and embrace the benefits that the Design Review brings to the final design.