UX/design practices and process
Process guidelines in a nutshell
- Artwork (low-fi or hi-fi) on Miro or Figma (Sketch deprecated)
- Please use links to
- Connect the artwork to the epic/issue
- Connect the epic/issue description/comment to the artwork
- Peer review on Zeplin
- Includes all stakeholders
- Zeplin allows asynchronous feedback
- Retains version history
- Zeplin is our central point to link off to Figma or Miro
- Assign at least one peer in the review stage as part of the Github issue flow
- Use the peer review metaphor to provide constructive feedback
Build things that are accessible by design
To make digital products accessible to everyone, we should think of accessibility from the beginning of the project, during the design stage. Not only does this immediately make our work more accessible, it reduces the risk of finding major accessibility issues late in development and needing to either start over or make compromises.
Do: Be rigorous from the first design stages, through coding, until QA.
Think creatively to come up with accessible solutions that follow WCAG guidelines and the principle of comparable experience.
Don’t: Wait until after development to do a QA on accessibility.
Accessibility on Vanilla Framework.
Discipline meetings
Design Assembly
A meeting dedicated to the whole design team: share topics and discoveries, ask for help and feedback, work together and show & tell. Everyone is welcome to attend.
UX/UI Vanilla working group
This is our working group to discuss issues and proposals on our design system. The design team with the Vanilla squad attend, but everyone is welcome.
Retro
This is a monthly retrospective meeting dedicated to the UX team to discuss what went well and what needs improvements over the last month. Together we discuss possible solutions and actions in order to improve.
Indicate the status of the project
Status can be used so that people know you are looking for feedback that reflects that status, e.g. ‘exploration’ (asking for feedback on UX and scoping, including implementation constraints and feasibility).
Use these labels across our tools, Miro, Figma and Zeplin.
Definition status
Includes phases such as (examples):
- Work on specs
- Definition phase
- Conceptual work
- User interviews
- Core engineers and stakeholders sync
- Personas, user stories
- Use cases, scenarios
- User journey
UX phase
Includes states such as (examples):
- First iterations of sketches/wireframes
- Wireframes (iteration 1, 2 etc)
- Final UX proposal (last wireframe to conclude UX)
Visual phase
Includes states such as (examples):
- Visual design (iteration 1, 2 etc)
- Feedback on the visual
- Final visual design/sign off
Development
- This is ready to be implemented
- Highlight implementation specs, annotation
What tools do we use?
We should work more on documents/specs and/or Miro to discuss things first, back and forth with engineers to discuss sketches about scope before moving to Zeplin for further feedback.
Docs and Specs
Spec docs with core engineers are also very important for the definition of the feature and to start a conversation around API, user stories and functionality. Start your project with specs and work with your entire squad and engineering team on the definition of these aspects.
Miro
Miro is very valuable, especially during the definition phase. You might want to consider starting in Miro during the definition and the initial stage of the project with core engineers instead of Zeplin.
Figma
Figma replaced Sketch app as our main design tool for phases that stretch from the definition to the visual design one. Some concepts need to be tested with a clickable prototype, we will publish a Figma prototype to collect interaction feedback. Name the page by iteration/phase of your work.
Zeplin
When ready for review, it can then move to Zeplin. Use tags and naming convention in a way that reflects the status of the project.
GitHub
We use GitHub (and ZenHub on top) as our tool to track work and progress on roadmap items (master epics) > epics > issues.
UX and design reviews are assigned on GitHub (have at least a peer assigned in review) and the sign-off is indicated with the use of “+1 labels”. This practice goes across the disciplines.
Dovetail
Dovetail is a SaaS repository for User Interviews and other research data. Ask in #User-research (on Mattermost) for an account and an introduction. Dovetail provides machine-transcription from video recordings. Dovetail will be the place where you tag your data and you can even use it to create reports based on your findings. Even if you don’t use all of those features, do upload all videos because (i) GDPR, (ii) future squad members will be happy to see previous reseach all in one place, and (iii) our templates provide suggested tagging - and therefore searching by tag across projects and products.
GetFeedback
Get Feedback - formerly “Usabilla” - lets you run (i) feedback buttons (e.g. to collect NPS-like data) and (ii) pop up surveys on our websites and products. We run several of these in the background to get a general heartbeat of feedback, and to recruit participants for specific studies or for our user panel. If you don’t already have a list of users for your product, start a survey now - on the pages where they spend time. Ask in #User-research on Mattermost.
Optimal Workshop
For IA testing, Optimal Workshop lets you run open and closed cardsorts. Your can intercept users from anywhere on our sites with GetFeedback and send them to an OW study, or invite them by email or even through social media campaigns. Ask for the credentials. We have a single seat.
Crazy Egg
As a Web and Design team we have a single account for Crazy Egg. It’s a useful tool to measure our websites from different angles: heatmaps, scrollmaps, confetti, overlays, recordings, for both desktop and mobile.
Google Analytics
Ask Peter to be included in our Google Analytics account, you can refer to David Calle for advanced investigations and analysis.
Publishing on Miro/Zeplin
Naming convention
Main section
To group all the projects we use the main section on Zeplin, which groups things on a cycle and product level. It should be named [CycleYY.MM Product]
Example: “22.10 Charmhub”
Projects name
Name your projects this way, using the year and the month of the cycle the project refers to: [CycleYY.MM] [Product] - [Project name]
Example: “22.10 Charmhub - Progressive release”
Project sections
- Name your sections and your artboards so they make sense to others. And to you, in 6 months time.
- Others need to know the phase, what they’re looking at and what kind of thing it is: “[Project status] - [Design name] [Iteration]”
Examples:
“UX - User flow sharpies sketch”
“UX - Initial sketches homepage”
“UX - Homepage wireframes V1”
“UX - Homepage wireframes V2”
“UX - Homepage wireframes V3”
“Visual - Homepage V1”
“Visual - Homepage V2”
- Try to upload new screens into new sections when the changes are enough to justify a new iteration of the work, let’s not replace screens (except for quick fixes and typos) when working on a new version of the iteration.
Zeplin status
A project should reflect the current status using the status option on Zeplin.
Links to specs/docs/epics
Put links to specs, docs or issues/epics in the description field, so people can find their way back to the spec and to the associated cards.
Inviting people to projects
- Consider you can invite people at different times. You want to focus more on getting feedback on functionality, user experience, visual? It doesn’t mean to invite these disciplines only, but to be clear on the status/phase of the project.
- Remember you can always use webteam@lists.canonical.com and design@lists.canonical.com to share and ask for feedback.
Resolving comments
- We should not resolve comments, let’s keep track of comments whenever possible.
- When a comment is addressed and completed we can then add ‘done’ to keep record of when things are closed, instead of resolving the comment.
- Uploading new screens on different sections will let comments stay where they originally were added: try to upload new screens into new sections when the changes are enough to justify a new iteration of the work. Let’s not replace screens (except for quick fixes and typos) when working on a new version of the iteration.
When do we comment?
Peer review metaphor
Soliciting feedback from our peers (other designers) should be more about asking “what haven’t I thought of” rather than “do you approve of my solution” - and more akin to a peer review than a critique.
As feedback-givers we should think twice before pressing “post” on an item of feedback and ask ourselves “does this comment further the goal of improving the end-user’s experience?”
There should be a level of mutual respect and trust, sufficient that comments are left (and read) with the best possible intentions and aimed solely at improving the end-user experience.
As design professionals, we should feel empowered to consider feedback and then incorporate or disregard it as we see fit. Of course, we shouldn’t dismiss all feedback but we should aim to strike a balance.
Design direction
If there are comments which are more fundamental about the feature, we should ping each other as opposed to leaving comments as this would lead to more confusion.
Does it need a comment?
Wonder whether it needs to be a comment at all, or if the matter requires a quick chat or a deeper understanding cross-discipline.
Add comments that use the feedback convention above to help the author understand your comments.
Last updated a month ago.