## Goal | User story | |:---------------------------------------------------------------------------| | As a User of Fleet's UI, | I want all UI elements to follow Fleet design patterns | so that I can have a consistently designed experience that is easy to use and look at. ## Context - Requestor(s): @lukeheath - Product designer: @rachaelshaw  ## Changes ### Product - [ ] UI changes: [Figma](https://www.figma.com/file/yISBqrTWvOLPRbcqFidErJ/%2317860-Improve-styles-for-license-expiration-banner?type=design&node-id=27%3A205&mode=design&t=Xr1ZFYjin6kce3N6-1) ### Engineering - [ ] Database schema migrations: TODO <!-- Specify what changes to the database schema are required. (This will be used to change migration scripts accordingly.) Remove this checkbox if there are no changes necessary. --> - [ ] Load testing: TODO <!-- List any required scalability testing to be conducted. Remove this checkbox if there is no scalability testing required. --> > ℹ️ Please read this issue carefully and understand it. Pay [special attention](https://fleetdm.com/handbook/company/development-groups#developing-from-wireframes) to UI wireframes, especially "dev notes". ## QA ### Risk assessment - Requires load testing: TODO <!-- User story has performance implications that require load testing. Otherwise, remove this item. --> - Risk level: Low / High TODO <!-- Choose one. Consider: Does this change come with performance risks? Any risk of accidental log spew? Any particular regressions to watch out for? Any potential compatibility issues, even if it's not technically a breaking change? --> - Risk description: TODO <!-- If the risk level is high, explain why. If low, remove. --> ### Manual testing steps <!-- Add detailed manual testing steps for all affected user roles. --> 1. Step 1 2. Step 2 3. Step 3 <!-- Consider: Do the steps above apply to all global access roles, including admin, maintainer, observer, observer+, and GitOps? Do the steps above apply to all team-level access roles? If not, write the steps used to test each variation. --> ### Testing notes <!-- Any additional testing notes relevant to this story or tools required for testing. --> ### Confirmation <!-- The engineer responsible for implementing this user story completes the test plan before moving to the "Ready for QA" column. --> 1. [ ] Engineer (@____): Added comment to user story confirming successful completion of QA. 2. [ ] QA (@____): Added comment to user story confirming successful completion of QA.
Goal
Context
Changes
Product
Engineering
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation