Skip to content

Hypotheses

Jump to bottom
Gavin Wye edited this page Jan 16, 2017 · 2 revisions

Each of the following hypotheses is drawn from a user need.

During alpha, we will be exploring a number of options based on these hypotheses.

  1. Designing and developing an agreed upon design language that all HMRC services should use will ensure consistency between those services

  2. Providing a single source of truth for all the patterns that are used to build HMRC's services will allow designers to work more efficiently

  3. Providing the insights from user research for a pattern alongside the pattern itself will help designers to understand the design decisions underpinning the pattern

  4. By providing users with guidance about using patterns, designers will be able to understand when (and when not) to use patterns

  5. By providing copy and pasteable template macros for a pattern's markup (as opposed to examples of its markup), designers will find it easier to maintain consistency and faster to implement than HTML

  6. Providing the status of a pattern will let designers know which patterns should be used (and which are currently works-in-progress)

  7. By making it clearer and easier to create and edit patterns, teams will be more willing to contribute their patterns to the community

  8. A clear, understandable, and well-communicated process will allow teams to be able to contribute patterns that meet their users needs more easily and quickly

  9. By providing a varied enough set of patterns, teams will be able to design services that are shaped around their users’ specific needs

  10. By providing a usable and suitable set of prototyping tools, designers will prefer to use them over other solutions and prototypes will become more aligned with one another

  11. By building the production code for patterns from the same source as the design language, production services will look like prototypes

  12. By showing examples of patterns as they appear in live services, designers will be able to make better decisions about which patterns they should be using

  13. By showing detailed results of a pattern’s research, we will stop repeat research being conducted on patterns that have already been tested

  14. A design language will reduce wasted time and energy when designing and testing services out of scope for alpha

  15. A working group will help teams understand when they need to make change or think differently about how they design their service out of scope for alpha

  16. By providing a shared resource for designers, researchers and developers teams will be able to collaborate more effectively out of scope for alpha

Clone this wiki locally