Skip to content

User needs and related hypotheses

Gavin Wye edited this page Jan 19, 2017 · 3 revisions
Number and priority User need Hypotheses Notes
1 As a service team We want to produce a service that is consistent within HMRC and aligns with the rest of government So that our users don’t have to relearn how to use our services Designing and developing an agreed upon design language that all HMRC services should use will ensure consistency between those services
2 As a service team We want one place to look for design patterns So that I don’t have to look all over the place and then invent something that somebody else may have done in the past 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 As a designer I want to see the results of user research for a design pattern So that I know it’s the right pattern to use to meet the user need I’m designing for 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 As a designer I need to know how a pattern should be used So that I know how and where it should be used when designing a service By providing users with guidance about using patterns, designers will be able to understand when (and when not) to use patterns
5 As a designer I need to know how to implement a pattern So that I know how it should be used when building a prototype 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 As a designer I need to know the status of a pattern So that I know if the pattern works or not Providing the status of a pattern will let designers know which patterns should be used (and which are currently works-in-progress)
7 As a service team We need to be able to create a pattern So that we can contribute this back to the design community By making it clearer and easier to create and edit patterns, teams will be more willing to contribute their patterns to the community
8 As a service team We need to be able to contribute a pattern this back to the design community So that we can meet the specific needs of the users we are designing for 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 As a designer I need variants of patterns So that I can meet the specific needs of the users I’m designing for By providing a varied enough set of patterns, teams will be able to design services that are shaped around their users’ specific needs
10 As a designer I want all teams to prototype in the same way So that I can work on different teams 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 As a designer I want the live service to match my prototype So that I can be sure that what has been built is what was designed By building the production code for patterns from the same source as the design language, production services will look like prototypes
12 As a designer I need to be able to see patterns in use So that I understand how a pattern is used in the context of a journey 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 As a user researcher I want to be able to see the detail of research that has been conducted* on a design pattern So that I don’t re-test patterns that have already been tested successfully *For example, who it was tested with, how the test was measured, what the outcome of the test was, what was the context, etc. By showing detailed results of a pattern’s research, we will stop repeat research being conducted on patterns that have already been tested
14 As the HMRC digital leadership team We need a clear and tangible means of supporting and evidencing our design language So that we can refocus the conversation towards bridging the gap between user needs and business needs A design language will reduce wasted time and energy when designing and testing services out of scope for alpha
15 As a service team We need to know what licence, responsibility, mandate we have to make change (if any) and where So that we can build a service that meets user needs 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 out of scope for alpha
16 As a service team We need to collaborate on designing services So that we can work in the most effective & efficient way By providing a shared resource for designers, researchers and developers teams will be able to collaborate more effectively out of scope for alpha out of scope for alpha
Clone this wiki locally