Elgato_dark/fleet
1
0
Fork 0
mirror of https://github.com/fleetdm/fleet synced 2026-05-24 01:18:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 59

fix: typo change He's to Here's (#5410)

Browse source
This commit is contained in:
Kelvin Oghenerhoro Omereshone 2022-04-27 16:22:44 +01:00 committed by GitHub
parent 0d0c17e0c6
commit 9263bff7dd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
handbook/company.md
View file

@ -192,7 +192,7 @@ Between overthinking and rushing, there is a [golden mean](https://en.wikipedia.
### 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.
He's why we use a wireframe-first approach at Fleet.
Here's why we use a wireframe-first approach at Fleet.
- 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.