Research Ready to Build: Compelling Artefacts that Speak Your Agile Team's Language
•Download as PPTX, PDF•
0 likes•163 views
Devashree Desai and Josh Ledwell, UXPA Boston 2020, October 23, 2020
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Research Ready to Build: Compelling Artefacts that Speak Your Agile Team's Language
Similar to Research Ready to Build: Compelling Artefacts that Speak Your Agile Team's Language (20)
Recently uploaded
Recently uploaded (20)
Research Ready to Build: Compelling Artefacts that Speak Your Agile Team's Language
- 1. Research Ready to Build: Compelling Artefacts that Speak Your Agile Team's Language Boston UXPA 2020
- 2. Who We Are Devashree Desai Senior Experience Designer | Autodesk Fun fact: Made living observing surgeries Josh Ledwell (he/him) Principal Experience Designer | Autodesk Fun fact: Once an online dating expert
- 3. VISION Agile versus UX • Agile is a powerful engine for building software. • UX research and design informing the solutions to effectively address real customer problems. • As Agile teams get deep into solving problems, the initial experience vision may fade. Initial UX vision Decide and Iterate Final product? DEVELOPMENT INTRODUCTION
- 4. Challenges fulfilling the initial experience vision DEVELOPERUX SPECIALIST INTRODUCTION • UX deliverables may not be relatable for developers. Formative Research Design Patterns Journey Maps Storyboard Specifications Test plan Requirements Code standards • UX researchers and designers may be separated from the Agile development team. They may be working ahead of the team.
- 5. Ask the audience Have you noticed a disconnect among research results, the initial design vision, and development work? Share examples from your experience in chat!
- 6. How to ensure your formative research findings and early design guidance will stay with your agile team over time? CASE STUDIES2 5LESSONS LEARNED
- 7. Case Study 1 Create a long-term UX strategy for customer data management
- 8. Customer Data Experience Strategy Align to company strategy Work with key customers Help developers plan Get stakeholder buy-in Define measurable success Enable team collaboration Desirable Feasible Viable Create a long-term experience strategy for managing customer data, and communicate it to guide four Agile teams’ work: ★ Goldmine – Boston, MA, USA Marvel – Shanghai, CN Seagull – Blackpool, UK Vibranium – Singapore The Problem CASE STUDY 1
- 9. UX SPECIALIST Journey Map StoryboardsBusiness Strategy Challenges informing the Agile process CASE STUDY 1 Presenting my research and design deliverables! Any questions? Experience Vision Phases
- 10. I am working ahead, and mostly alone, while the teams are executing on different short-term priorities. CASE STUDY 1 Working ahead
- 11. ? CASE STUDY 1 When it is time to make the strategy real DEVELOPER UX SPECIALIST . . . ?
- 12. CASE STUDY 1 Show how the code evolves with the experience
- 13. • Much greater engagement and collaboration on the strategy • Collaboratively built out a scope of work CASE STUDY 1 Results Storymap
- 14. Case Study 2 Improving a complex feature with functional dependencies on other parts of software
- 15. The Problem CASE STUDY 2 • Walls – Basic building block and the most used feature. • Different personas use “Walls” in different ways. • Functional dependencies on other building elements. • Improvements in the existing feature to accommodate contemporary building designs and practices.
- 16. CASE STUDY 2 Early User Research • Working solo before team actively started working on it. • Lots of UX artefacts • Discovery phase research = Areas of opportunities • Multi year, multi team effort project.
- 17. How might we move forward to improve this feature and provide incremental value to the customers? CASE STUDY 2 Building a Shared Vision Areas of Opportunities Technical Dependencies Shared Vision • “Why” are we doing this? “What” is the ultimate experience our users need? • Never coming to conclusion/next steps. • Risk of creating difficult to maintain code and gaps in the experience. Ultimate Experience
- 18. SMALL ENHANCEMENTS NOT DEPENDENT ON STEPS ABOVE PHASE IIPROJEC T MAP PHASE I ULTIMATE EXPERIENCE Vision Map for Incremental Improvements CASE STUDY 2 Critical Path Optional Path
- 19. When the development starts • Anticipated time crunch to complete feature for the release. • Risk of losing important functionality for the users. • Turn user research insights into actionable work for everyone in the team. CASE STUDY 2 DEVELOPER UX SPECIALIST Test plan Development tasks Prioritization of tasks and epics Design tasks, Ongoing research questions QA PRODUCT OWNER “What should work” document
- 20. “What Should Work” Document CASE STUDY 2 Status Functionality User NeedCurrent Behavior External dependency Epic JIRA task Questions/ Assumptions Means to resolve Test Complete Complete Complete Complete Complete Insert doors and windows in Slanted Walls Doors and windows can be inserted vertically. Should be able to insert doors and windows either vertically or along the slant of the wall. Need a new parameter to select between the two options. Decide the terminology for the new parameter. Wall Inserts REVIT- 15306 Pending Complete Complete Complete Complete None
- 21. 5 Lessons Learned What worked for us…
- 22. Create compelling artefacts that speak to the team • "Speaking the language" is not just extra work. • Your team is more likely to understand your deliverables. They don't have to learn a new thing. • When your artefacts are closer to the team's language then it is easier to translate into the work to be done. 1
- 23. Show how the design is built upon the research learnings • Bring back early insights when the team actively starts working on the project. (Repeat, repeat) • Show how the design is built upon the research insights. • Hold yourself and the team responsible for staying true to the research insights with design acceptance criteria. 2
- 24. Hijack Agile Ceremonies • Utilize the Agile ceremonies to zoom out and see the big picture. • Keep reinforcing because your guidance will fade over time. • Create focused collaboration events - design critiques, workshops, customer testing events etc. 3
- 25. Keeping it fresh for stakeholders • Reach outside of your team for understanding and buy-in. • Inspire stakeholders to represent your vision by appealing to their values. 4
- 26. Sustaining not just the artefact, but also your sanity • Sustainability of the artefact over time and projects. • Your team will get into the habit of working your way. • Burnout is real right now! Commit to what makes sense. 5
- 27. What’s Next Make artefacts easy to maintain. Get the team actively involved in maintaining and enriching the artefacts. CONCLUSION Evolve and formalize the practice across different projects and scopes. Spread the practice and increase our sphere of influence. Agile Team Wider Org
- 28. Thank you!
Editor's Notes
- Thanks for being here, everyone. Welcome to (title). My partner and I will briefly introduce ourselves.
- Both of us speak to this slide
- Lets talk about UX in the context of agile team setting, shall we? (switch for Devashree) Agile is a powerful way to develop software iteratively and Many of us work using Agile methodology. Josh and I are embedded in different agile teams where we work closely with developers, QA and product owner. (switch for Devashree) The process is best informed by UX research and design, so you know your solutions effectively address real customer problems. (switch 2 times for Devashree) Over time, though, the initial experience vision may fade as Agile teams get deep into solving problems.
- Why does that happen? What are some of the challenges in front of the agile teams that might cause this deviation from the initial vision? (switch for Devashree) UX researchers and designers may be separated from the Agile development team They may be working ahead of the team while the rest of the team is completing some other priorities. (switch for Devashree) UX researchers and designers create experience maps, survey results charts Importance/difficulty matrix as part of the deliverables. (switch for Devashree) On the other hand developers might describe things differently in terms of code standards, software requirements, test plans and so on. (switch for Devashree) Because both the disciplines speak different languages - UX deliverables may not be relatable for developers in understanding the exact next steps from their POV and this might result in the initial vision getting lost especially in later stages. (switch for Devashree)
- You can share examples from your experience in the chat. We would love to hear about them. Josh to monitor chat. Looks like people have experienced this in their work.
- So the bigger question we are trying to address is (read the question) We will take a look at 2 case studies where we will talk about how we approached similar problems within our agile teams. We will also talk about important key lessons we learned through that process.
- Our customers use 3D software called Revit to create building models that represent an entire construction project, and enable them to accurately predict cost, effort and time to build the real thing. They need to keep track of all kinds of data, from doors and windows to lists and parameter values – everything that goes into designing a building. Switch to Josh
- Create and socialize a long-term experience strategy for managing customer data. The teams are all in different locations and time zones, so communication would be a challenge. (consider if more here) Tie into higher levels of business strategy Strategy to guide four Agile teams
- I did this to communicate this …. Etc Slow down and discuss each deliverable Apparent when I presented my UX deliverables to the teams, I didn’t get any questions! This was because I was working ahead
- When I worked on and delivered the strategy … Working ahead, mostly along, because the team was executing on short term goals. “As one example of customer data”
- We got to the key meeting: Time to translate aspects of the experience strategy to backlog items we can develop When can we have the high-level experience requirements for the next piece of work? We can’t do that first. We have to address a technical dependency first. Hold on. Something just came up that we need to fix. (time passes) What’s the next piece of work, and when can we have the high-level experience requirements? Clearly the strategy deliverables had not communicated effectively. I realized I needed to speak in a language that would stay with the teams
- And so (narrate the diagram) "shows the computing power / intelligence / automation that helps customer make better choices" I talked about the challenges with the team’s SW arch and exp architect. The architects suggested that I outline the code components and how they would change over time Example of Chauncey Wilson’s track usability defects as bugs Adding code components to the diagram I start getting questions on the implementation Sequence? Dependencies? Priorities? Feasibility?
- The team was able to storymap, our process for writing user stories matched to a customer workflow In fact we’re now building, come to fruition What’s the status now? Lessons learned – would you start it earlier in a process like this Find ways to cut down on 1:1 meetings
- In this second case study I will talk about
- As Josh mentioned earlier, we work on a software that helps in designing buildings. As you can imagine “walls” are the basic building blocks probably the first thing anyone creates inside Revit. Architects, structural engineers, electrical designers and many other personas use “Walls” in different ways. For ex. Architects design walls to envision the space doors and windows while structural engineers would be concerned with the stability and construction of that wall, electrical engineers would want to place lighting fixtures on the wall. The walls literally hold the roof but when you change the wall - the changes also reflect in roofs, floors, windows, doors etc. So ”Wall” is an existing functionality. But now the challenge for the team was to modernize this feature in a way enables users to intuitively design contemporary buildings with contemporary forms, materials, and practices.
- As a part of early research I worked ahead of the team, did surveys and interviews and produced a variety of UX deliverable's. These outlined opportunities areas in the overall experience. I was able to identify many short term and long term opportunity areas and it was soon clear that this is going to turn into a multi year multi team effort project.
- As we geared towards the prep for the development work, the team realized we need more clarity on the next steps. (switch for Devashree) After several rounds of technical conversations withing the team it became apparent that we need to build a shared vision. (switch for Devashree) Because of all the functional dependencies I mentioned earlier, I realized that if we don’t think about technical dependencies early on in the vision, we would end up creating something that might provide immediate value but it won’t scale up well over the years. we would be at a risk of creating difficult to maintain code which wont scale up well with the improvements over the years. (switch for Devashree) Read the question (How might we…) We collaboratively worked together to bring area of opportunity and technical dependencies to build a shared vision. (switch for Devashree) Based on the research insights I tried to Imagine the ultimate experience we want to provide to the users and then identiied sizable chunks of work that could provide incremental value to the users. The first iteration of the vision looked like this…linear roadmap that could take us several more years to provide ultimate experience. Is that going to provide real value to the users considering the return of investment?
- Build a realistic vision which strikes balance….between providing values to the user and return of investment (switch 3 times for Devashree) I considered a critical path instead of linear path which would enable to team to provide value with each release and accelerate the path towards the ultimate vision. (switch for Devashree) (switch for Devashree) Also identified smaller projects which other teams could help with that would have no dependency on the main project phases. Socialized this map among stakeholders and customers. Because it included both the customer and technical perspective, it remained fresh with the team. So much so that the team started thinking about flexibility of the code to accommodate the future improvements in the roadmap. Questions in the end about first step/Once identified the first step, because of this functional dependencies on other parts of the buildings, we wanted to make sure important functionality does not get lost.
- Once a first step was clear for the team, we had another hurdle. Because the team was working on other priorities, I anticipated the time crunch we will face at the end. With the that, there was a higher chance that we would have deviated from our vision of providing the functionality important for the users with this first release and just done something that is easy to do in the given time frame. I also needed to think about how to make that vision more actionable and relatable for the team so our ramp up time with this project is less and instead use that time in developing all the must have functionality. (switch for Devashree) So I took an inspiration from QA test plan. QA test plan defines exatly how should the feature work and in this case work with other parts of the building – for ex. once a change is made into a wall how it should behave with roofs, floors, etc. The idea was to not just outline the behavior but also a create a repository of associated UX questions and assuptions that needs testing upfront and means to resolve it so that we are not blind sided. The aim was to create a backlog of tasks for everyone that is relatable and actionable without being vague. (switch for Devashree) So every team member got what they think is important to complete their work.
- Talk about the titles how it helped the team.
- Now that we have seen the 2 case studies, lets look at the 5 lessons we learned.
- First lesson through these case studies is Create compelling artefacts that speak to the team. UX deliverables that we create early on the process sometimes fail to strike a chord with the team especially when the team is working on competing priorities, the team needs something tangible to move forward quickly. (Switch for Devashree) And that’s why speaking the language of your team is important. In both the case studies, we tried to incorporate artefacts that were inspired by the considerations and deliverables of our teammates like code components and what should work document. (Switch for Devashree) When you speak the same language UX deliverables are likely to stay with the team and they don’t need to learn anything new to grasp those. Once that happens, less time is spent to come to a shared understanding as a team and it is easier to get buy in from them. (Switch for Devashree) When the artefacts are closer to the team’s language, they find them more relatable and actionable. It doesn’t stay as your artefact but a team artefact which helps everyone to identify their part of work.
- The second lesson is to Show how the design is built upon the research learnings. (Switch for Devashree) Most of the times, research happens way before the team actually starts working on the project. It is practically not possible that team members would remember the insights that you presented at that time. So Bring back those early insights to the team when they actively start working on it. (Switch for Devashree) Make sure you show your team how the design is built on research insights. Connect the dots back to the insights when you present design options. This will ensure the team understands the heuristics important for the the users that came up in the early research. (Switch for Devashree) Repeating the insights will not only help the team empathize with the users but it will help you and the team responsible for staying true to the insights with design acceptance criteria. (Switch for Devashree) Now Josh will talk about the next few lessons
- Switch to Josh When you’re working Agile, your team meets regularly for specific purposes. Often these include daily Scrum, backlog refinement, sprint planning, and Sprint Review. (point 1) You can take advantage of these moments to review longer-term work. For example, I will demonstrate long-term strategy work in Sprint Review, and I may add a “look ahead” to backlog refinement to the team’s next big chunk of work. 2) (read the point) 3) (read the point) Sometimes taking time in Agile ceremonies isn’t enough, and you need to carve out specific time to focus on collaborative design and on getting feedback.
- The fourth point, keeping it fresh for stakeholders, is similar to the previous point, but for your clients, customers, managers, and people outside the team who care about your work. (point 1) Make sure stakeholders are aware of the foundational research and design you have done. Later you can refer back to it when the team is building the design. (point 2) And then, (read point). You really want stakeholders to not just be aware of your vision but to be excited about it and speak well of it to others. Take the time to understand what your stakeholders value, and show how executing on the vision will help. For example, one of the engineering managers I work with is always concerned about incremental delivery: showing value to customers as often as possible in the course of a large project. Adding code components to the experience vision showed how we would deliver incrementally, and it inspired her to represent our vision when communicating to peers throughout the organization.
- Now, all this can seem like a lot of extra work. So our fifth point is not to do too much. Your research and design practice needs to be sustainable. (point 1) Consider from the beginning how you will maintain your artefacts. For example, I use Mural and Powerpoint over many other design tools because they make it easy for others to open and edit my documents. The other day I asked teammates to send any updates to my Mural stakeholder map. A development manager told me that some contacts had changed, and she would just quickly change the Mural herself. (2) Referring to early research and design can become a habit for your. If you consistently
- How to evolve practices to subsequent phases, different projects, and different scopes, so we can formalize the practice.