Elgato_dark/fleet
1
0
Fork 0
mirror of https://github.com/fleetdm/fleet synced 2026-05-23 17:08:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 83

Handbook: Update product-groups.md (#16952)

Browse source 
- After driving the process along the CEO from 2020-2023, the Head of
Product Design took over for the CEO in the role of DRI for design
reviews in mid-to-late 2023 (I missed this update in the handbook)
- Added some other notes about how async participation works, since it
looks like we may have lost that philosophical language in the great
handbook migration from the departmental pages out into "Product groups"
This commit is contained in:
Mike McNeil 2024-02-18 15:00:14 -06:00 committed by GitHub
parent f3cbea355a
commit d60463dc1b
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 8 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
handbook/company/product-groups.md
View file

@ -641,14 +641,19 @@ Design consultations are scheduled as needed with the relevant participants, typ
- Discuss implementation details
### Design reviews
Design reviews are [conducted daily by the CEO](https://fleetdm.com/handbook/digital-experience#calendar-audit).
Design reviews are conducted daily between the [Head of Product Design](https://fleetdm.com/handbook/product-design#team) and contributors proposing changes to Fleet's interfaces, such as the graphical user interface (GUI) or REST API. This fast cadence shortens the feedback loop, makes progress visible, and encourages early feedback. This helps Fleet stay intentional about how the product is designed and minimize common issues like UI inconsistencies or accidental breaking changes to the API.
The product designer prepares proposed changes in the form of wireframes for this meeting, and presents them quickly. Here are some tips for making this meeting effective:
Product designers or other contributors come prepared to this meeting with their proposed changes in a GitHub issue. Usually these are in the form of Figma wireframes, a pull request to the API docs showing changes, or a demo of a prototype. The Head of Product Design and other participants review the changes quickly and give feedback, and then the contributor applies revisions and attends again the next day or as soon as possible for another go-round. The Head of Product Design is responsible for looping in the right engineers, community members, and other subject-matter experts to iterate on and refine upcoming product changes in the best interest of the business.
Here are some tips for making this meeting effective:
- Bring 1 key engineer who has been helping out with the user story, when possible and helpful.
- Say the user story out loud to remind participants of what it is.
- At the beginning of describing your change, indicate whether you are 70% sure you are 100% done, or are looking for early feedback.
- Avoid explaining or showing multiple ways it could work. Show the one way you think it should work and let your work speak for itself.
- For follow-ups, repeat the user story, but show only what has changed or been added since the last review.
- Zoom in.
- Read Fleet's [best practices for meetings](https://fleetdm.com/handbook/company/communications#meetings).
> To allow for asynchronous participation, instead of attending, contributors can alternatively choose to add an agenda item to the "Product design review" meeting with a GitHub link. Then, the Head of Product Design will review during the meeting and provide feedback. Every "Product design review" is recorded and automatically transcribed to a Google Doc so that it is searchable by every Fleet team member.
### Weekly bug review
QA has weekly check-in with product to go over the inbox items. QA is responsible for proposing “not a bug”, closing due to lack of response (with a nice message), or raising other relevant questions. All requires product agreement