·
1. Synchronise development
You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.
2. Increase design literacy
The more your team knows about user experience and design, the less they need you. This is a good thing. Leave good books laying around. When you make a recommendation explain why. With a good team of smart, happy people (i.e. an agile team), they’ll pick the basics up really quickly. Once the rest of your team can handle most things by themselves, it’s like there’s more you, and you can focus your expertise on the more wicked problems.
3. Collaborate more and more often
Get in the same room and sketch, point, talk, and iterate. By the time you’re done with the conversation, every one has a good, consensual idea of what you’re building. In the end, a consensual idea is why you document. If everyone leaves with the same idea in their heads, then the last reason you have for documenting is recording details that might fall out of people’s heads. Things like how a list is ordered, or what happens if there’s an error. As above, you can spend less time on basic documentation and focus on what documentation is good at: remembering things you won’t.
4. Be flexible as a rubber band
Documentation is still a good thing, but the more details you have, the longer your document takes to produce. Wireframes are the best example of this. A well-annotated, high-fidelity wireframe for one page can take a day, easy. If you need to spend less time, use fewer details. If you’ve collaborated on the design, and you’ve helped improve their design literacy, then your team won’t need all the detail. Strip your documents down to the basics and only deliver what people need. Make your wireframes more like page description diagrams or block layouts.
5. Speak their language
Book your time the way the development team does. Use their systems and their language. Use story points, tickets, and time tracking. Only commit to what your estimates say you can commit to. If something starts to take longer, communicate the change in the timeline. The agile system manages this (by bumping lower-priority items off the sprint).
