= User research process = ||<>|| * '''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 * Move to [[#communicating| Communicating results of user testing]] === 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 * Move to [[#communicating| Communicating results of user testing]] <> == 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''