Building UI Components - Requirements Gathering
I thought it might be useful to document a non-exhaustive list of things to consider when building a new UI component. It's most likely that only a small subset of the items below will be of use for any given feature, but I've found it super useful over the last few years to at least consider each of the following. I've also referenced a few resources I've found myself revisiting quite often.
- What is this component composed of?
- Does this component need to be reusable?
- If so, can we make it generic enough?
📁 State & Data
- Does this component need to hold any local state?
- Can we keep it presentational/dumb and pass the data concerns on to a parent component/the application?
- How should we handle invalid data?
- What is the data model?
- Can we optimise the data structure(s) used to improve performance?
- What are this component's inputs? i.e. props, data passed down
- Does it need to listen to/for anything?
- What are this component's outputs? i.e. events, HTTP requests, web socket messages
🎨 Styling and Animation
- What assets do we need?
- How do we load/host any assets?
- How should the component handle missing/unavailable assets?
- How do we handle unexpected data? i.e. extreme text lengths, a high number of items to render
- Are there any performance considerations with any animations needed on various user devices?
- Do we need to handle right-to-left (RTL) reading directions?
- Can the component work without CSS? do we need to worry about this?
💙 A11y requirements
- Ensure you review checklists/resources such as the a11y project
- Will we need to organise mob testing using an array of commonly used screenreaders?
- Can we ensure the component is keyboard navigable?
- Does it make sense for this component to undergo any form of a11y testing by an external provider?
- Smashing magazine has a great reference for building accessibile components
🗺️ i18n requirements
- Can we ensure designs work correctly across the languages of our users?
- Don't impose English centric normalities on users from other countries!
- Do we need to support right-to-left (RTL) text? Doing so will impact things like media object layouts, icon placement etc.
- Consider reviewing the i18n best practices from W3C
- How can we measure the performance of this component?
- What would be considered good/bad performance? Are there any risks?
- How do we handle slow/poor/no network connections?
- Consider reading up on the RAIL model and similar concepts
- Do we need to perform any intensive processes? Can these be optimised or mitigated?
⚠️ Error handling
- What kind of failures could occur?
- Do we need to implement any logging? (info, warning, error, fatal etc.)
- Can we get visibility of issues?
- How do we handle any resources failing to load
- Have we discussed/agreed to any fallback behaviours if something breaks?
- Do we need retry strategies for any actions that could fail?
- Can we implement feature toggling to release this feature safely to users? Consider reading up on feature toggles
🌐 Network behaviour
- Do we need to support Offline?
- Should we respond to changes in the connection?
- Can we/should we progressively enhance the experience for better connections? i.e. load higher resolution images if there is a good connection and appropriate pixel density?
- How should we deal with poor connections?
- Are we handling user input?
- Consider keeping an eye on the OWASP top ten
- Does this component introduce any new packages or 3rd party scripts?
- If so, consider reading OWASP's guide to 3rd party management
📊 Tracking and analytics
- How can we measure whether or not this component is being interacted with?
- How will we know if people love or hate this component?
- Do we need to run this component through A/B testing to validate it?
- Will we know immediately if there are any negative consequences when releasing this component to real users?
- Are there any additional analytics requirements for this new component?
💻 Browser support
- Do we have a list of browsers we intent to support?
- Do we need to consult caniuse when developing
- Can we import our google analytics user statistics into caniuse to measure support for new frontend features amongst our existing user base? reference
📱 Device support
- What is the lowest spec device we can expect this to run on?
- What screen sizes are we building for?
- Do we have desktop/mobile users? Could this change?
- Unit tests?
- Automated browser testing?
- Visual regression/Snapshot testing?
- Accessibility testing?
The above is by no means an exhaustive list, nor will they all apply to every component you build. The complexity of a basic button in a single country may differ wildly from a sophisticated search box that speaks to a backend and is used across eight countries.
I believe that the above is a good start. You'd want to answer most of the questions ahead of time rather than have to scramble for the answers later in the journey.