Agile is here to stay. Corporates love it, start-ups embrace it and developers live by it. So there is no denying that Agile is going nowhere and we have to work with it. For a number of years, I’ve tried to align User Experience practices with Agile methods and haven’t met with great success every time.
But nevertheless, there are a lot of lessons that I’ve learnt during the process and I’m going to share 7 tips that always worked for me.
Create a shared vision early on
Get all the decision makers (Dev leads, Project managers and Project sponsors) in one room. Get a whiteboard and discuss why are we developing this product? What problems are we trying to solve? Once you have an overall theme, ask more specific questions such as how many app downloads are we targeting in the first week?
This workshop will give you a snapshot of a shared vision and common goals of the organisation. During every checkpoint of this project, this shared vision will serve as a guide, helping teams prioritise user stories and make the right trade-offs along the way.
This workshop will give you a snapshot of a shared vision and common goals of the organisation. During every checkpoint of this project, this shared vision will serve as a guide, helping teams prioritise user stories and make the right trade-offs along the way.
Engage stakeholders wherever possible
Regardless of how many people in your team are in agreement, most of the times the decision makers are the Project Sponsors or Division Managers. You do not want them to appear randomly during sprint 3 planning and poop on it.
I highly recommend cultivating strong relationships with these stakeholders early on in the project. Invite them to all UX workshops, and if they can’t/don’t attend, find a way to communicate the summary of the meeting in an engaging way (not an email with a PDF attachment). I use to put together a Keynote slide and have it ready on my iPad for a quick 5-minute summary.
I highly recommend cultivating strong relationships with these stakeholders early on in the project. Invite them to all UX workshops, and if they can’t/don’t attend, find a way to communicate the summary of the meeting in an engaging way (not an email with a PDF attachment). I use to put together a Keynote slide and have it ready on my iPad for a quick 5-minute summary.
Work at least one sprint ahead of the Dev team
The chances of getting everything from research, wireframes, designs and development done for a single card – in one sprint is implausible.
You’ll struggle to get everything going at the same time. When you are designing, the developers are counting sheep because they are waiting on you to give them something to work with. You don’t want to be the reason behind the declining burn chart. Always be at least one sprint (if not two sprints) ahead of the development team. Sometimes it takes longer to research and validate design decisions, but if you are a sprint ahead – you are not holding up the developers, and you have ample time to respond to design challenges.
You’ll struggle to get everything going at the same time. When you are designing, the developers are counting sheep because they are waiting on you to give them something to work with. You don’t want to be the reason behind the declining burn chart. Always be at least one sprint (if not two sprints) ahead of the development team. Sometimes it takes longer to research and validate design decisions, but if you are a sprint ahead – you are not holding up the developers, and you have ample time to respond to design challenges.
Foster a collaborative culture
Needless to say – Collaborate as much as you can. Try to get the team involved (just the people sitting around you is fine) for even small things such a changing a button’s colour. It makes them feel important; makes them feel good and fosters a culture of collaboration.
If you don’t collaborate with the team on small (or big) things, don’t expect them to tell you everything either. Your opinion might not be very valuable in most of the Dev discussions such whether to use ReactJS or Angular, but knowing that the Devs are going to use a certain JS Library – will definitely help you in (one or the other way) planning future sprints.
If you don’t collaborate with the team on small (or big) things, don’t expect them to tell you everything either. Your opinion might not be very valuable in most of the Dev discussions such whether to use ReactJS or Angular, but knowing that the Devs are going to use a certain JS Library – will definitely help you in (one or the other way) planning future sprints.
Follow an Iterative Design Process
DO NOT design mock-ups, to begin with. I know all the customers want to see something real that they can sell to their bosses. But the pretty design approach falls on its face every time. I want my customers to detach themselves from aesthetics and focus on structure and interaction first. Once we have worked out the hardware, then we can look at building the software.
Try Iterative Design Process. Sketch on the whiteboard, get the stakeholders to put a vision on paper and come up with a structure first. Then iterate. Here is my design process:
Try Iterative Design Process. Sketch on the whiteboard, get the stakeholders to put a vision on paper and come up with a structure first. Then iterate. Here is my design process:
- Paper sketches
- Low fidelity wireframes (on white board / PC)
- Interactive wireframes – B/W (on PC)
- Draft Designs – in Colour
- Final Designs
- Pass onto the build team.
Do a round of user testing with at least 5 people
User testing is not expensive, it does not take days or weeks, and you don’t have to talk to 25 people.
There is a lot of research on how testing only 5 users is highly effective and valuable to product development. Pick users from different demographic, put an interactive wireframe together and run it past them for about 30 – 45 minutes. After 3 users, you’ll start noticing common themes appearing. And after 5, you’ll have enough pointers to take back to the team for another round of iteration. Repeat this process every two to four sprints.
There is a lot of research on how testing only 5 users is highly effective and valuable to product development. Pick users from different demographic, put an interactive wireframe together and run it past them for about 30 – 45 minutes. After 3 users, you’ll start noticing common themes appearing. And after 5, you’ll have enough pointers to take back to the team for another round of iteration. Repeat this process every two to four sprints.
Hold a brief stand-up meeting every day
Hold a stand-up meeting first thing in the morning. The aim is to keep everyone updated on progress, recognise blockers and pick-up new cards. This ensures all the team members are on the same page and are working towards a common goal.
However, be mindful of the time since some discussions are lengthier and may need to be taken offline. We generally time-box stand-ups for 15 minutes.
However, be mindful of the time since some discussions are lengthier and may need to be taken offline. We generally time-box stand-ups for 15 minutes.