empayre/fleet
14
0
Fork 0
mirror of https://github.com/empayre/fleet.git synced 2024-11-06 17:05:18 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add missing links (#10669)

Browse Source 
..
This commit is contained in:
Mike McNeil 2023-03-22 01:12:18 -05:00 committed by GitHub
parent 1ec14fc144
commit f5c8daacf0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
handbook/company/why-this-way.md
View File

@ -80,10 +80,11 @@ To check out the right person to review a given piece of content or source code
## Why do we use a wireframe-first approach? ## Why do we use a wireframe-first approach?
Wireframing (or "drafting," as we often refer to it at Fleet) provides a clear overview of page layout, information architecture, user flow, and functionality. The wireframe-first approach extends beyond what users see on their screens. Wireframe-first is also excellent for drafting APIs, config settings, CLI options, and even business processes. Wireframing (usually as part of what Fleet calls ["drafting"](https://fleetdm.com/handbook/company/development-groups#making-changes)) provides a clear overview of page layout, information architecture, user flow, and functionality. The [wireframe-first approach](https://speakerdeck.com/mikermcneil/i-love-apis) extends beyond what users see on their screens. Wireframe-first is also excellent for drafting APIs, config settings, CLI options, and even business processes.
Here's why we use a wireframe-first approach at Fleet. It's design thinking, applied to software development.
Here's why Fleet uses a wireframe-first approach:
- We create a wireframe for every change we make and favor small, iterative changes to deliver value quickly. - We create a wireframe for every change we make and favor small, iterative changes to deliver value quickly.
- We can think through the functionality and user experience more deeply by wireframing before committing any code. As a result, our coding decisions are clearer, and our code is cleaner and easier to maintain. - We can think through the functionality and user experience more deeply by wireframing before committing any code. As a result, our coding decisions are clearer, and our code is cleaner and easier to maintain.
- Content hierarchy, messaging, error states, interactions, URLs, API parameters, and API response data are all considered during the wireframing process (often with several rounds of review). This initial quality assurance means engineers can focus on their code and confidently catch any potential edge-cases or issues along the way. - Content hierarchy, messaging, error states, interactions, URLs, API parameters, and API response data are all considered during the wireframing process (often with several rounds of review). This initial quality assurance means engineers can focus on their code and confidently catch any potential edge-cases or issues along the way.
@ -97,6 +98,7 @@ Here's why we use a wireframe-first approach at Fleet.
- With Figma, thanks to its powerful component and auto-layout features, we can create high-fidelity wireframes - fast. We can iterate quickly without costing more work and less [sunk-cost fallacy](https://dictionary.cambridge.org/dictionary/english/sunk-cost-fallacy). - With Figma, thanks to its powerful component and auto-layout features, we can create high-fidelity wireframes - fast. We can iterate quickly without costing more work and less [sunk-cost fallacy](https://dictionary.cambridge.org/dictionary/english/sunk-cost-fallacy).
- But wireframes don't have to be high fidelity. It is OK to communicate ideas for changes using ugly, marked-up screenshots, a photo of a piece of paper. Fleet's [drafting process](https://fleetdm.com/handbook/company/development-groups#making-changes) helps turn these rough wireframes into product changes that can be implemented quickly with minimal UX and technical debt. - But wireframes don't have to be high fidelity. It is OK to communicate ideas for changes using ugly, marked-up screenshots, a photo of a piece of paper. Fleet's [drafting process](https://fleetdm.com/handbook/company/development-groups#making-changes) helps turn these rough wireframes into product changes that can be implemented quickly with minimal UX and technical debt.
- Wireframes created to describe individual changes are disposable and may have slight stylistic inconsistencies. Fleet's user interface styleguide in Figma is the source of truth for overarching design decisions like spacing, typography, and colors. - Wireframes created to describe individual changes are disposable and may have slight stylistic inconsistencies. Fleet's user interface styleguide in Figma is the source of truth for overarching design decisions like spacing, typography, and colors.
- While the "wireframe first" practice is [still sometimes misunderstood](https://about.gitlab.com/handbook/product-development-flow/#but-wait-isnt-this-waterfall), today many modern high-performing teams now use a [wireframe-first methodology](https://speakerdeck.com/mikermcneil/i-love-apis), including [startups](https://www.forbes.com/sites/danwoods/2015/10/19/dont-get-ubered-apis-hold-key-to-digital-transformation/?sh=50112fea182c#:~:text=One%20recommendation%20that,deep%20experience) and [publicly-traded companies](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design).
> Got a question about creating wireframes or the drafting process? Mention Noah Talerman or Luke Heath in `#help-product`. > Got a question about creating wireframes or the drafting process? Mention Noah Talerman or Luke Heath in `#help-product`.