I work with my team to continually look for better and more effective ways of working. I’m a big fan of agile and iterative practices, but without a dedicated Scrum-master, it’s pretty hard to do full agile, IMHO. Over the past few weeks I’ve put together the following process for a UX and Design team to work to.
It incorporates many techniques that I think are vital to successfully delivering work:
- Regular reviews
- Stakeholder input
- Regular reviews (both with the team and with stakeholders)
- A style guide
This process was built around not having direct access to developers – so it needs to sit within a wider Waterfall process, with a handoff into the development cycle.
1. Project initiator(s) work with UX to:
- Articulate the business needs/requirements,
- Articulate the user needs/requirements,
- Articulate supporting research (where applicable),
- Commission additional research, analytics support etc.
2. Project group assigned, which includes:
- project initiator(s)
- front end developers,
- back end developers,
- project manager,
- business analyst,
- business representative(s) as applicable.
3. [ KICKOFF ] Carry out a Design Jam for the feature:
- UX presents research and frames what the objectives are,
- Group breaks into smaller, multi-disciplinary teams,
- Teams brainstorm and sketch:
- user journey/flow
- pages and components
4. UX refines and elaborates the user flow and sketches.
5. [ ITERATE ] Sketches reviewed by team at weekly iteration review meeting.
- Team breaks down features as much as possible,
- Gives ROM (rough order of magnitude) estimates given for each story/task.
6. Milestone plan drafted and stakeholders identified (by UX and PM).
7. [ APPROVAL MILESTONE ] Sketches & plan reviewed by project stakeholder(s).
8. [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.
9. Front end Developer works with UX to create a prototype of the sketches.
10. [ ITERATE ] prototype reviewed by team at weekly iteration review meeting.
11. Informal user testing is carried out on the low fidelity prototype.
12. [ ITERATE ] Refinements as per testing incorporated.
13. Team reviews sketches/prototype in context of style guide (and component library), to determine how many new style elements and components are needed.
14. Designer begins works on new components needed for the project.
15. UX begins to create formal wireframes.
16. [ ITERATE ] Creatives & Wireframes reviewed by team at weekly iteration review meeting.
17. [ APPROVAL MILESTONE ] Creatives reviewed by stakeholder(s).
18. [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.
19. [ DELIVERABLE ] Front end developer refactors low fidelity prototype (where necessary) and applies style to match creative design.
20. [ DELIVERABLE ] Designer updates style guide/component library. (The concept of delivering page level creatives is no longer necessary. We work on a style guide and update components, as necessary, and add new components as they are designed and signed off).
21. [ ITERATE ] Team reviews functioning feature/pages at weekly iteration meeting, ensuring that it meets the sketches & wireframes.
22. Testing carried out on functional (but not plumbed into the backend) feature/flow.
23. [ ITERATE ] Refinements as per testing incorporated and reviewed .
24. [ APPROVAL MILESTONE ] Final deliverables reviewed by stakeholders.
25. [ ITERATE ] Agreed refinements as per Stakeholder feedback incorporated.
26. [ DELIVERABLE ] UX creates detailed wireframes, documenting state changes and interactivity, and adds them to the component library. This becomes a primary resource for the test team, along with the user flow(s).
27. [ DELIVERABLE ] Style guide updated.
28. Front end developer works with backend developer to ensure that front end code is integrated as per standards, and that the same quality of code that was provided (by the front end developer) is being returned by the application server.
29. [ MILESTONE ] Project team and stakeholders sign off integrated feature.
30. [ ITERATE ] Team reviews pages/components/features as they are integrated into the back-end systems, and carries out user testing as necessary. Any changes as a result of seeing the integrated work is specified and scheduled.
So, I know that this is a bit of a brain dump, and I’ll add some rationale at a later point. But I’d love to hear any and all thoughts and feedback you may have. Have I missed something? Is there something that can be taken out?