In Agile sprints, designers rush, make user assumptions, and design in isolation due to the fact that they feel pressed for time and want to ensure they deliver a design output, which traditionally constitutes completion or success of the sprint. This may cost tech and design debt in the long wrong, mainly when the necessary research-driven processes are not taken into account. Design solution may result in misalignment, implementation will need rework, which will require more time, effort, resources, and product delivery postponement.
Lead a research-informed, collaborative, and organized Agile UX sprint process for a confident UX solution.
In this article, I will describe the necessary tasks for each day of the sprint, with reasons for importance, and what you must do to execute them.
Day 1: Design brief
Kickoff meeting with PM and developers - set a meeting up with your pod PM and developers to align and set expectations for the required features to be designed. Define the scope of the design (how long do you estimate it will take in story points), the timeline (for your key activities), goals (what you're going to achieve), user stories (the problems you are trying to solve), strategy (the process you will take to get to a solution, and outputs (what you will deliver by sprint end).
Schedule all sprint meetings - use your calendar to start blocking out time for your user interviews, executive meetings, mid-sprint design reviews, design activities (UI/IA, report building, note organization, etc), concept tests, and follow ups. This will prepare those you need to speak with in advance, ensure availability, and ensure you make progress against your schedule.
Create task tracking for all requirements and activities - use JIRA (or other task tracking services) for creating tickets to track your status, requirements, communication, and design artifacts, measurement, etc. This will ensure alignment, organization, and process.
Day 2: Research
Analyze competitor research - assess 3-5 of your key market competitor services and products. Focus on specific functionalities or features. Jot down user assumptions/goals, step by step details of workflows and micro-interactions, and pros and cons. Create a comprehensive report showing a table comparing your competitors features, screenshots of your competitor's designs, and other data analysis or metrics to give insight and direction.
Interview 3-5 users - designate at least an hour with a direct user of the feature you are designing. In these user interviews, you will be moderating non-directive user questions about a task workflow, job, or goal. This is an opportunity to listen, and to poke and prod on user behaviors, pain points, and perhaps design recommendations.
Consult technical and business stakeholders - designate at least an hour for each tech and business expertise related to the feature or service you have to design. In these sessions, you will moderate specific questions about technology and business opportunities, ROI and KPI definitions, and any ideas they may have to solve the problem. Take notes and ensure your designs are linked to business and tech factors.
Day 3: Report
Summarize your findings, insights, and hypothesis - Create a comprehensive report that highlights common and differentiated user behaviors, key insights, data analysis, and a hypothesis of what the design may be or the exact problem defined based on your meetings with users, technical peers, and business associates.
Present to team - ensure you've schedule time with all stakeholders and pod on this day to present your report to. Take note of ideas, feedback, and follow up questions for your users, and action items that arise during this meeting. Schedule follow up meetings and ensure execution of action items.
Day 4: Work sessions
Collaborate with users, designers, PM's, and developers - sessions can be broken apart into 1 on 1 with each user or peer, or can be combined with everyone. You can run these sessions as some form of a design sprint. Conduct ideation techniques, brainstorm exercises, and whiteboard sessions. The objective is to ensure creativity and solution. The output of these sessions may still be notes or high fidelity and loose design concepts.
Synthesize research - Take your findings from the work sessions and start to organize ideas, notes, and thoughts. Tease out ideas into more details through sketching or rough notes. The point here is to riff on ideas and push the needle deeper.
Day 5 and 6: Information architecture
Formalize outcomes from work sessions into design visualizations - the next couple of days should be allocated to creating user journey maps, flow diagrams, wireframes, service blueprints, sentiment mapping, etc. Use templates to start populating your data and ideas. These will be used to illustrate your findings in a structured and story-telling way to your stakeholders. These will also help to ensure you are solving the right problems, defining a solution, presenting opportunity, and highlighting gaps. You can also use this time to document KPI and ROI returns and how might the design solve for those.
Review with your team, then iterate - ensure you've schedule time with all stakeholders and pod on the sixth day to present your report. Take note of ideas, feedback, and follow up questions for your users, and action items that arise during this meeting. Schedule follow up meetings and ensure execution of action items.
Day 7 and 8: Design
Create UI designs and prototype - translate your wireframes into detailed high fidelity designs. Create your specs, interaction behaviors, and design for edge cases and error handling cases. Ensure your design reflect your system design patterns and components. Build your prototype in parallel, which will be used in your concept tests, as well as reviewing with your development team.
Review with team, then iterate - show your team the designs. Take note of technical implications, solution alternatives, and other feedback. Alter your designs and spec based on the changes made.
Prepare concept test plan - write out your script and the user stories you will be testing against your prototype. Prepare you introduction, step-by-step guidance, or your testing strategies, techniques, and questions for your users. You can run these sessions as usability tests, ideation sessions, or for more user interview clarity.
Day 9: Test
Moderate and observe prototype tests - schedule 3-5 one hour prototype/concept tests with your users. If remote, make sure to record your sessions for future reference. If onsite, pay attention to eye tracking, mouse/keypad behaviors, and postures. If testing usability, ensure you are observing more than you are speaking. You want to see how the design functions on its own. Ensure you reserve time at the end of the sessions to get feedback on general thoughts about the experience and if there are other improvements that can be made.
Build report analysis with findings and changes - produce a comprehensive report analysis of the concept tests. Illustrate some key analytics or metrics, common and differentiated user behaviors, insights, and possible changes to be made on the design. Present this to your pod and stakeholders and take note of any further feedback and follow up user questions.
Day 10: Finalize
Update design based on feedback from concept tests - once you've received final inputs from your team and users, you will update the UI designs suitably within the technical limits and sufficient to the user needs, while satisfying usability factors.
Present final design to team and stakeholders - show your final designs to your team, users, and stakeholders. Any feedback, required changes, or additional follow up user questions will need to be planned for the next sprint or placed in the backlog for proper prioritization and timeline. If they are light enough and if you have time, then go ahead. After your meetings, your time should be focused on asset and spec preparation and hand over to the development team.
Close tickets and append all design artifacts - ensure you've marked your tickets complete. Attach all of your reporting documents, notes, specs, and assets. Create additional tickets for outstanding items that need more attention and research, then place in the backlog.
Summary
It's a sprint, not a marathon, go fast, light, with control
Get info to give you confidence to make the best design decisions
Choose your velocity, strategy, and activities as you see fit
Deliver value at sprint-end, even if just learnings
Put forth a solution, and iterate in subsequent sprints
Comments