-
Notifications
You must be signed in to change notification settings - Fork 4
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 |