How to Improve the Iterative Design to Agile Development Workflow

Hector Aristy, Pablo Pérez at UXDX Community: Agile Design, Team Building & Metaphor-Driven UX. Video: https://youtu.be/QqCEU72LzQI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Pablo: Welcome everyone to our talk. We're really excited to be here and to be able to share with you some of the things that we have learned through our journey of building products. Today we will discuss the crucial integration of UX design within agile development in order to create better products.

[00:00:23] Pablo: I'm going to start with a little presentation of myself. My name is Pablo, as I've already said, and I'm a software engineer by trade. When I was coding, what I enjoyed the most was designing and coding the UI, so I naturally transitioned into UX over a decade ago and completely forgot how to code. Over the years I've been partnering with clients from startups to public companies to build digital products for many industries, such as retail, healthcare, logistics, entertainment, finance and real estate, among others. And I am also a cooking, especially grilling, and TV series enthusiast.

[00:01:06] Hector: My name is Hector. I have around six years of experience in the software engineering field. Like Pablo, I shifted to the management position because I was looking for something different, and that was helping collaborators to grow in this software engineering career, but building their own custom career paths. Just a fun fact: I'm a coffee lover, and also I started to play pickleball, so I'm considered like a pickleball player.

Iterative design and agile development

[00:01:38] Pablo: Cool. So now we're going to explore how UX design and agile development can be integrated to enhance and refine user experiences and to foresee and address technical challenges. First, we want to talk quickly about what iterative design and agile development is. Iterative design involves a process where ideas transition from concepts to prototypes, which are then tested and refined based on user feedback. This process basically transforms an idea into a product, and this cycle of ideation, prototype, test and refine is key to evolving high quality user experiences.

[00:02:34] Hector: So from the agile development overview, to have a big picture of what it does, it just prioritizes flexibility, continuous deployment and the delivery of functional software through shorter sprints. Early on, frequent feedback from iterative design enriches this process.

[00:02:55] Pablo: When UX design and agile development work in harmony, the benefits extend beyond just the finished product. Enhanced communication ensures all team members, whether in design or development, are aligned with the project goals from the start, avoiding misdirection and wasted effort, and creating a unified vision of the product. By involving UX from the early stages, we can identify and address usability issues much earlier in the process, which not only saves time but also significantly improves the overall user experience. And ultimately this collaboration leads to products that better meet user expectations and drive higher user satisfaction, adoption and engagement.

Design sprints, and integrating UX into agile sprints

[00:03:51] Pablo: To integrate this UX design process into development, we run what we call design sprints, and these sprints consist of a set of five stages. Stage one is to understand the problem that is going to be tackled in this sprint. Stage two is to sketch different solutions to that problem. Stage three, to decide what is the best solution, or the combination of solutions. Stage four is to build that prototype based on that solution. And stage five, which is to test with users to validate the solution that we chose and to get user feedback. It is after applying the most relevant feedback that the handoff to engineering happens, so they can implement the work in the current or in a future sprint.

[00:04:43] Pablo: But to effectively integrate the UX design process into agile sprints, it is very crucial to involve UX designers from the outset, from the start. This means aligning UX and development goals during the sprint planning phase, ensuring that every sprint reflects both functional and user experience objectives. Also conducting shared design workshops that help build a mutual understanding of the project, allowing designers and developers to collaborate together in a more efficient and effective way.

[00:05:23] Pablo: Also embedding UX tasks, such as user research, prototyping and usability testing, within these sprints, to create a robust feedback loop enabling the iterative refinement of both the product's design and functionality. And if you follow this approach, this will not only enhance the product but also foster a more collaborative and innovative team environment.

Accommodating design in the development workflow

[00:05:53] Hector: So, how do we integrate those design sprints in our development workflow? Accommodating UX design in the development workflow requires thoughtful planning and flexibility. During sprint planning especially, we need to allocate time for those UX deliverables, ensuring they are treated with the same importance as the development tasks. Foster a culture of cross-functional pairing, where developers and designers work closely together, allowing for real time problem solving and innovation.

[00:06:29] Hector: Implement feedback loops directly into your sprint to quickly interact with the UX findings. This allows us to give pretty quick feedback about something that we saw in the design. Also UX can tell the developers that something changed because of some high needs. And additionally, adopting version control for design similarly enables seamless collaboration across the entire team. This integrated approach not only streamlines the workflow but also enhances the synergy between design and development.

Tools for collaboration

[00:07:16] Pablo: So effective collaboration between UX and development is often facilitated by the right set of tools. These systems serve as a shared language, reducing the back and forth and ensuring consistency across the product. Tools like Figma and Abstract offer version control for design assets, enabling designers and developers to work on the latest designs at the same time. And also shared prototyping tools allow teams to collaborate in real time, providing immediate feedback and fostering a more dynamic development process. Communication platforms such as Slack and Jira ensure that updates, changes and decisions are communicated seamlessly, keeping everyone on the same page. These tools not only improve collaboration but also significantly enhance the efficiency and the productivity of both teams.

Common challenges and how to overcome them

[00:08:16] Pablo: Even using these tools and tips, in our journey towards integrating UX and agile we often encounter roadblocks that, if not carefully navigated, can derail our efforts to create better user-centered products. Let's see some of the most common challenges and how to overcome them.

[00:08:36] Hector: So one of the main challenges is frequent communication misunderstandings. I think this is something pretty common in like every software industry that has a design team and also a development team. They always have some miscommunication, because a lack of clear communication is going to lead to delays, frustrations and products that miss the mark of user satisfaction. To combat this, I think we can adopt a culture of open and regular communication. Daily standups can help with that, because both designers and developers can be involved in giving their information. Also we can use these sessions not just to report on what we've done, but to share insights, ask questions and clarify understanding across the team. Encourage the use of collaborative tools where ongoing work is visible to everyone, and these decisions can be documented and referenced.

[00:09:36] Hector: Shared goals. So shared goals is another thing, aligning on user needs and technical feasibilities. It's not uncommon for teams to work in silos, each with a clear focus on their specific objectives. However, this can lead to a disconnect between the product design and its technical execution. So to prevent this, start each project phase or sprint with a joint session where user needs and technical considerations are discussed. Use this session to establish shared goals that reflect both impeccable user experience and technical prowess, ensuring every team member is pulling in the same direction.

[00:10:22] Hector: Respect for expertise, valuing inputs from both sides. A diverse team brings varied expertise to the table, but differences can sometimes lead to tensions, especially on tight deadlines. It is crucial to foster a culture where each team member's expertise is respected and valued. Encourage knowledge sharing sessions where designers can learn about technical constraints and developers can gain insights into design principles, expanding each other's empathy. This not only enriches the team's skill set but also builds a mutual respect, understanding and trust, making collaborative problem solving more effective.

[00:11:10] Pablo: And adjustment of practices. Agile methodologies are inherently flexible, but we often find ourselves sticking to rigid interpretations of processes. Be open to evolving your practices. If conventional sprint lengths don't allow you to do effective UX research and testing, consider adopting a dual track, where discovery and development run in parallel, allowing for continuous learning and adaptation. Similarly, if your team struggles with integrating UX design into development, experiment with different models of collaboration, such as having UX designers lead the feature kickoff workshops, or co-creating design and development tasks. This will also enhance the product development process and lead to innovative, user-centered products that stand out in the market.

[00:12:07] Pablo: So together we create better products. Overcoming these collaboration barriers requires a proactive, strategic approach. By fostering a culture of frequent communication, aligning on shared goals, respecting each team member's expertise and maintaining flexibility in your practice, you can build a robust framework for integrating UX design and agile development. Integrating this practice empowers teams to create products that are not only functional but also intuitive and delightful to use. So that will be all from our side. We are open to any question you might have. I hope you enjoyed all the insight in the presentation.

Q&A

[00:12:49] Host: Excellent, thank you very much Hector and Pablo. So yeah, just to reiterate, everybody out there, if you have any questions please do write them in, whichever platform you're watching this on, if that's YouTube, LinkedIn or the UXDX site, and I'll put those questions through to Hector and Pablo. So I guess one of the first ones that I have is around the miscommunication, because that is kind of the essence of the problem, I guess, that kind of miscommunication. You touched on it about the handover from design and dev. Do you try to merge the teams at all, to get more devs involved earlier, so that it's less of a handover and more of just an inbuilt knowledge?

[00:13:38] Pablo: Yeah. Well, even though we have two different disciplines involved in the sprint, we work as one team to tackle all the challenges together. Even though we have different tasks, we try to involve engineering as soon as they are available, so we can get more insight on what the technology can do. So they are involved in most of the design decisions, and when we hand over the designs it is just to show them what the final version of the feature looks like, not to introduce a whole new feature from scratch.

[00:14:21] Hector: Yeah, so from the development perspective, it does help us a lot. It saves us time about thinking where are the things we are going to implement, and also we are aware of where the client needs are pretty early, so we can focus. When UX delivers something we can right away flag something and say, hey, this might be going the wrong way, or maybe this is going the right way.

[00:14:49] Host: And how are you getting that? So you've gotten this and you've been involved in that kind of research and understanding, okay, this is the feature, this is the finalized feature that we want to build. Are you iteratively releasing that in smaller chunks to customers to try and get feedback, or how do you break up that kind of, here is our product, so that you can release a slice of it and get that user feedback?

[00:15:17] Pablo: Yeah, we try to prioritize what is the most present issue for our market, and we try to prioritize those small features first. And then when they are launched we develop KPIs to understand how the user behavior around those features is, and if they're not hitting the mark we can prioritize a version two of that feature for the next sprint.

[00:15:46] Host: Excellent. So I'm going to ask the thorny question, because this is the one that always catches me as well as a lot of other people out there, that, let's go back for a V2. What's the biggest lie in software? It's, we'll fix that in V2. So how do you make sure that you do have funding for the V2, versus the, oh well, it'll be better just to get the next feature out, the next feature out, the next feature out?

[00:16:15] Pablo: That's a very good question, and we often go to that conversation with budget limits and time limits. But as we build the product in this way from the start, it's an easy conversation, because we know what the impact of not doing that version two means. It could mean the product is dead right now, and if we have budget left it's time to reallocate that into another idea, because this one is dead because we didn't do version two of this main feature that was what the market was looking for. So it's an easy conversation because we have the facts, but it's a difficult conversation.

[00:17:00] Host: And what are your metrics? So are you measured on, because in a lot of companies it'll be a business case, so it's predictability, are you on time and on budget? Or do you have business metrics that you're measured on, to say, it doesn't matter if you build the tiniest thing as long as you hit these outcomes?

[00:17:20] Pablo: Well, we do have normal metrics while we're building the products, if we're on time and on budget. But every feature needs to have a business need, or a problem that the user needs to solve. So we create specific metrics for that feature, and we just keep on getting data and validating if this feature is working the right way, even though we built it on time and in budget. Whether the feature is performing in the market as we expect, or not.

[00:17:55] Host: Okay, so which one takes priority though? Again, I guess I'm just asking it from a different angle, which is the exact same thing as the V2 question, because what I've often seen is people will give lip service to the outcomes. So how do you battle that, when people are saying, oh, you should get the outcomes but you should also make sure you're on time and on budget?

[00:18:18] Pablo: Sure. And again, it depends on the feature and what KPIs it's impacting. If this is a core feature that makes or breaks the product, it's something that we need to take care of right now. If it's a satellite feature that enhances something that we already built, and that thing that it enhances is the core feature and it's performing, then that could be something for a next release, and let's prioritize something that is core now.

[00:18:51] Host: Excellent. So that sounds like an amazing process, and I think some people might be listening and being a bit jealous, because you've actually gotten into a situation where you can do this and a lot of people wish they could. So do you have any advice for somebody who's sitting in a more traditional company where it's all about the on time and on budget, and they're maybe not even tracking the effectiveness of their features? What are the steps that somebody who's either in design or development could do right now that can help them move in that direction?

[00:19:31] Pablo: Well, first of all is to understand what the feature means, what's the purpose of the feature, because a feature is a tool, so what's the problem that that feature is trying to fix? And start measuring it, and sharing those metrics with the product team. And well, numbers don't lie, they will tell their story, and it will empower you to have a voice at that table of, this feature is not working, here's the data, we need to do something about it.

[00:20:06] Host: And Hector, do you have anything to add on that?

[00:20:09] Hector: Yeah, so from the developer perspective, I will say, be open when some designers come to you with those features, because maybe you will learn something new when they're trying to show you, let's say, the V2 version. Also your input is valuable as a software engineer, because maybe we have some technical limitation that the designer hasn't seen yet, so that's something valuable for them. Because, like I say, we have to work together as one team, and that's something that we have been doing, and we're doing pretty great with that.

[00:20:57] Host: Awesome, I always like hearing closer collaboration. So let's enter back into the real world. We've painted this lovely perfect rosy picture, but what are the things that are still the problems for you, and what are you trying to work out at the moment? And what are the kind of experiments or activities that you're testing to try to solve some of the still present issues that you have in your process?

[00:21:30] Pablo: Well, believe it or not, the most difficult part is to get the initial momentum into this process, because if you have nothing to show it's hard for people to believe in the process. But once it's running, it speaks for itself. So the hardest part, and what we're trying to make better, is that initial conversation, that initial stage of a new product or a new version of a product, where you have to tell all the stakeholders, please trust the process, this will get us where we need to be.

[00:22:11] Hector: I think, like Pablo said, the first initial step is the pretty hard one. Some clients are difficult to adapt to our process, so in some cases they are not as proactive as we want. So sometimes we have to push them or show them that that's something that is going to give us a pretty good outcome.

[00:22:37] Host: Yeah. I was chatting to a guy, Richard Rodger, he runs a developer relations consultancy, Voxgig, and he said that building trust, because you're asking clients to trust you a bit more, versus here's a spreadsheet and now I want to tick off everything that's on the spreadsheet, it's more of a trust based relationship. And he talked about the concept of a trust battery that he needed to charge as soon as possible. Do you have any tips for how you get that trust? Because as you said, that is one of the hardest parts, is getting that trust and that buy-in up front. Do you have any tips for how you've charged your trust battery, or whatever metaphor, I have to use a metaphor today, but whatever metaphor you'd like to use?

[00:23:26] Pablo: Yeah, that's an excellent metaphor. One of the things that we do is we try to prioritize a small chunk of work first, just to show them as quick as possible a very good increment on the process and on the product, so they can not only hear from us but actually live it and see it working. We practically choose a very small feature just to run the process with, and in three, four, five weeks they can see something of value, and they continue to charge that trust battery on the process.

[00:24:08] Host: And do you have, I guess more from a technical perspective, because in a lot of the companies I've worked in, it's definitely getting better, but I wouldn't be able to release something in three, four weeks, because there's a path to production and it's congested, and it's difficult to get your slot in there, and long test cycles and things like that. So how do you overcome those challenges that would be present and that you might not have control over?

[00:24:40] Hector: So we try to make those features divided, to be backward and forward compatible, we try that. Also we have different environments where the client can see the progress of everything. Let's say maybe we are working those five weeks on the product, but if that client goes to, let's say, that staging environment, they can have a kind of preview of what we currently have at the moment. In that way he can interact with that, and maybe can give us some feedback, saying, hey, maybe I thought this feature was going to be like this but I was wrong, maybe I have to think in another way. And in that case we can save a few weeks and maybe we can do the change really quickly.

[00:25:28] Hector: That also requires a solid infrastructure, and also solid best practices about coding, everything, because if we do it without that compatibility it will be chaos just to release that feature in the future.

[00:25:47] Host: Excellent. So that's some great advice on picking something small and making sure, I think Pablo you alluded to this, making sure it's a usable feature. Instead, a lot of companies break things down by functional areas, but then you haven't got anything until you've got everything. So it's good to get something that actually is working. Or do you have something to add on that?

[00:26:11] Pablo: No, that's right.

[00:26:16] Host: All right. Does anybody else, I feel like I'm hogging the questions here, I'm just looking to see if there's any comments from the audience. So, Shy[?] and Albert, you were commenting, Gonzalo, Liz, if you have any questions to add, please don't be shy and post them in. I guess we just have two minutes left before our next talk, so do you have any kind of last parting advice that you would like to share with people on how together we can create better products?

[00:26:55] Host: All right, are there any job openings at GBH?

[00:26:59] Pablo: You're welcome to visit our website and our career page.

[00:27:06] Host: Excellent. All right, so I think that we might finish two minutes early then. So I just want to thank you once again, Pablo and Hector, for sharing how you approach software development, how you tackle the challenges of the handover and the communication between design and dev. I think it was really interesting, and I hope people out there learned as much as I did.

[00:27:31] Pablo: Thank you for having us, Rory.