launchpad development|
Size: 2966
Comment:
|
← Revision 7 as of 2012-03-05 17:57:58 ⇥
Size: 3717
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| == Process Overview == The user research project template sets out the process required for conducting and implementing user research results and recommendations from initial questions to updated mock-ups/prototypes. |
== Process overview == |
| Line 12: | Line 11: |
| === Process Description === '''User research process''' '''1(a) New design for a new project – flat mock-ups''' |
User research helps us to build the right features in Launchpad and to make sure we're on the right track while we're building them. This is a lightweight process for requesting, conducting and acting on user research. == Process description == The types of research we conduct, and how we conduct them, are a result of the needs of the Launchpad team and the constraints that we work under. For the most part, we want to know about people's behaviours: i.e. what people do and where Launchpad fits in. That can help us to know what features to build and how they should function. Similarly, we're mostly interested in qualitative research. If we're clever about picking the right people, qualitative research can give us deep insight from speaking to a relatively small number of people. This process will grow to describe how we handle other user research needs. == 1. Commissioning research == === 1(a) New design for a new project – flat mock-ups === |
| Line 19: | Line 33: |
| * 2. Communicating results of user testing | * Move to [[#communicating| Communicating results of user testing]] |
| Line 21: | Line 35: |
| '''1(b) Designs part-way through development – flat mock-ups or prototypes''' | === 1(b) Designs part-way through development – flat mock-ups or prototypes === |
| Line 28: | Line 42: |
| * 2. Communicating results of user testing | * Move to [[#communicating| Communicating results of user testing]] |
| Line 30: | Line 44: |
| '''2. Communicating results of user testing''' | <<Anchor(communicating)>> == 2. Communicating results == |
| Line 34: | Line 49: |
| ''Designer Input'' | === Designer input === |
| Line 39: | Line 55: |
| ''Squad Lead Input'' | === Squad Lead input === |
| Line 47: | Line 63: |
| '''Communicating changes to mock-up/prototype''' | == Communicating changes to mock-up/prototype == |
| Line 49: | Line 65: |
| UX Report Sheet used to document what changes need to happen and have been agreed, to either the mock ups or the actual design, based on the research. | We use the UX Report Sheet to document what changes need to happen and have been agreed, to either the mock ups or the actual design, based on the research. |
User research process
Contents |
Name: User research process
Owner: Dan Harrop-Griffiths
Effective: 2012-03-02
Process overview
User research helps us to build the right features in Launchpad and to make sure we're on the right track while we're building them.
This is a lightweight process for requesting, conducting and acting on user research.
Process description
The types of research we conduct, and how we conduct them, are a result of the needs of the Launchpad team and the constraints that we work under.
For the most part, we want to know about people's behaviours: i.e. what people do and where Launchpad fits in. That can help us to know what features to build and how they should function.
Similarly, we're mostly interested in qualitative research. If we're clever about picking the right people, qualitative research can give us deep insight from speaking to a relatively small number of people.
This process will grow to describe how we handle other user research needs.
1. Commissioning research
1(a) New design for a new project – flat mock-ups
Usability Specialist talks to Squad Lead / Designer about new design and preliminary testing. Questions are either open-ended, or set questions for specific features are agreed.
- Plan for tests documented
- Tests conducted
1(b) Designs part-way through development – flat mock-ups or prototypes
Usability Specialist discusses potential UX issues with Squad lead / Designer, talk about what things Squad Lead / Designer would like clarity on. List of potential ideas put together for questions, depending on what we want to find out at this stage.
- Actions for user testing documented
- Usability Specialist conducts tests
- Usability Specialist writes up test results
2. Communicating results
UX Report Sheet – Usability Specialist puts recommendations into report sheet
Designer input
- Call with Designer to discuss how recommendations impact design
- Designer adds comments relating to design principles
- Design changes to mock-up / prototype agreed
Squad Lead input
- Call with Squad Lead to discuss how recommendations impact implementation and to highlight any potential implementation difficulties relating to UX
- Squad lead adds comments relating to possibility of implementation
(Product Manager / Project Manager to look over design/implementation comments if necessary)
- Implementation changes to mock-up / prototype agreed
Communicating changes to mock-up/prototype
We use the UX Report Sheet to document what changes need to happen and have been agreed, to either the mock ups or the actual design, based on the research.
Changes made to mock-up/prototype in line with what was agreed. This can be as simple as a tick or ‘done.’
- If not done, there is a space to explain reasons why.
- If something extra is done, there is a space to explain reasons why.
Reasons for changes and extra features discussed between Squad Lead and/or Designer, with Usability Specialist.
(If necessary - Product Manager / Project Manager to review changes and make decision for the UX cause or the implementation cause, depending on scope/timeframe/resource/affect on user.)
New wireframes signed off, ready for next stage of tests
