Bringing design into an agile development workflow

George Box used to say that "all models are wrong, some are useful". Mental models, diagrams, flows, and schemes are our attempt to understand how something works. They are never perfect, as all simplifications end up ignoring some of the situation's particularities. The way designers work here has much more nuance than what I'm about to show, but this model can generate insights and discussions nonetheless.Our design team is fairly young and small, and we are still shaping our process. Adding a series of design steps into a workflow that used to focus exclusively on development is not an easy task, and it has been a huge learning experience for me. So keep in mind that none of this is set in stone. The way people work together is always evolving, and I really hope our workflow gets even better in the future.As <a href="https://www.vinta.com.br/playbook/">Vinta's playbook</a> says, "each project is unique and requires its own tools. There is no such thing as the best language or an only way to do things." Depending on our relationship with the client, the context of a particular feature or a number of other factors, this workflow can behave very different to what I'm describing here. Our teams work on products at very different stages. Some are on the market for a while, and both the client and our team has tons of user data to guide the decisions about the system we are building. Others are not launched yet, so the best we can do is validate concepts and look at how other companies are solving similar problems before jumping into development.<figure class="kg-card kg-image-card"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/e0/0b/e00b9f5b-e060-49d5-be9b-fe222c8e88c1/gif-design-process.gif" class="kg-image" alt="alt text"></figure> This little GIF shows some different paths that can happen in our workflow, and the many iterations that usually happen. It varies a lot depending on the feature's complexity and its priority on the development roadmap.<h2 id="how-we-communicate">How we communicate</h2>Since all of Vinta's clients are abroad, our entire team makes an effort to have seamless communication with the least possible noise. We have a dedicated design channel on Slack with our clients where we can get quick feedback and check-in daily. But the most important interaction happens on weekly design meetings, which we added to the development process.Each product team at Vinta has a weekly sprint meeting with the client. To bring design into the workflow, our first attempt was discussing design and development in the same meeting, to see how it would go. After a few iterations, we decided to break the two subjects apart in order to maximize efficiency.Participating in the sprint meetings in my early days in Vinta was very useful. It helped me understand the dynamics of an agile development sprint, see what kind of issues the product was dealing with and feel like part of the team. But it wasn't very efficient overall, so we had to adjust. We found out that the best way to discuss new features and get feedback on new ideas for the product is to have a separate design meeting, attended by the designer, the project manager, and the client. The PM's presence here is crucial because they have a deep understanding of how the system works, what are its limitations and what's the impact of a new feature on the existing structure.Communication within the team is also very important. Given that I was introduced to ongoing projects instead of starting something from scratch, much of my work is understanding how the current system works in order to shape new parts of it. I'm constantly aware of what my dev teammates are working on, and our teams have dedicated internal channels to talk about specific areas of the product (e.g. front-end, metrics, logistics, bugs). We also sync whenever a big feature request comes up, and do sprint retrospectives to discuss how our workflow can be improved.I could spend a few more paragraphs on the many things I'm learning about building rapport with developers and establishing trust with clients, but that's subject for another blog post. Let's break down our workflow already!<h2 id="the-workflow">The workflow</h2><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/a2/39/a2397edd-1ed4-42eb-8c4d-d740cc87326c/flow_4.png" class="kg-image" alt="alt text"><figcaption><a href="https://vinta-cms.s3.amazonaws.com/media/filer_public/a2/39/a2397edd-1ed4-42eb-8c4d-d740cc87326c/flow_4.png">click here to see it on full-screen</a></figcaption></figure><h2 id="1-feature-request">1. Feature request</h2>Our process for designing a new feature usually starts with a request from the client. In the case of a B2C product (which is what I'll be using as an example), the need for that feature can be motivated by a series of factors: the competition is doing something interesting that could work for our client's product; The support team noticed some users are having trouble using a part of the system, and it needs to be redesigned; Our client has a new customer retention strategy that involves creating a way of bringing users back to the platform through reactivation coupons, etc.Sometimes we get a brief description of the new feature before the weekly design meeting, which gives us some time to do a quick research on it. Most of the time, though, our client brings it up on the design meeting itself. The PM and the designer have a few goals for these new feature briefings:Understand the purpose of developing this feature. Where is it coming from? What was the motivation behind it?Define the feature requirements. What should users (both customers and admins on the business side) be able to do? What are their needs? What will they achieve? How will their experience be improved?Define the feature's priority on the roadmap. That can change (and often does), but it's important to know how this development will relate to other things that are already on the team's track.Define success metrics. What do we want to measure? What makes this feature successful? What are the parameters we can experiment with?<h2 id="2-user-flow">2. User Flow</h2>After we have a good idea of what the new feature is, the PM assigns a developer who will be working on it. It's nice if the person who is actually going to implement the feature is invested in understanding and shaping it together with the designer. Then we have a user/system flow session. This is the moment when we break out the post-its and sharpies, and I found it to be a really fun and engaging activity for the developers. The physicality of doing things with pen and paper brings us away from technical constraints and forces us to think about the big picture.Represent the user flow for the new feature, in a super-low-fidelity prototype. This is when we get creative and think of ways to satisfy the users' needs and bring the client's requirements to life. I like to think in terms of pages (where the users are in our system), actions (what they do here) and pathways (where they go).Assess the feature's impact on the system. When we're building on top of an existing architecture, it's rare to have self-contained features that can be built independently. So we need to understand how it connects to other parts of the product and the constraints that come from that.Assess the feature's complexity. In many situations, it's hard to get an accurate idea of the feature's complexity in the first briefing. Things that look simple sometimes have a much larger impact on the system (it happens a lot with features that don't have a lot of UI). Depending on the feature's complexity, we may need an additional sprint to do some thorough research on it. It may involve competition benchmark, search for tools that can be useful or analysis of user data.Specify all use cases for the feature. This is the moment to ask all the "what ifs" we can think about. What other paths can users follow inside this flow, besides the desired one? What happens if they make a mistake? One example: we were building a customer reactivation campaign, where we gave a discount to users with canceled or suspended accounts upon reactivation. So, what happens when a customer reactivates their subscription but pauses their package delivery right after?Raise issues to clarify with stakeholders. Sometimes, even with research, we need additional information about the feature requirements, especially when it's highly complex. We then take note of everything that needs further discussion and bring it up on Slack or on the next design meeting.After the session with the team, I retire into my fancy design software and work on representing the user flow in a way that the client can easily understand it. For some features, it's a diagram. For others, it's a <a href="https://www.smashingmagazine.com/2014/10/the-skeptics-guide-to-low-fidelity-prototyping/">lo-fi prototype</a> of the feature's navigation. I usually present the flow to the client in the next design meeting, and then we discuss it in more detail. This is, more often than not, the magic moment when the feature gets defined. Sometimes the client and I discover a new use case or an additional requirement, and I iterate upon that new information.<h2 id="3-research">3. Research</h2>Every new feature on a product needs some level of research. Designers are always searching for solutions that have worked in other contexts, so we don't have to reinvent the wheel on every project. The most common types of research we do are:Competition benchmark: If we're building something that competitors are already doing, I need to understand how they're doing it and what would be the best course of action. The analysis can range from a few insights on the use of modals to a document with a detailed taxonomy of content elements across a dozen websites. Sometimes a simple thing as a CTA update needs a little benchmark to give me an idea of what is a good standard in this scenario.User base analysis: When a feature is going to have a big impact on a section of our users (e.g. all inactive users will receive a discount upon reactivation), we need to know how many they are, what was their behavior in the recent past, how often they were receiving their subscription before they cancelled the account, etc. This is the kind of information that is always at hand but gains meaning and power when we look at it with curiosity.Similar solutions in different contexts: This kind of research happens more on specific UI problems. What are the best practices for form input fields? What's the nicest way to deal with error messages on the UI? What is the standard for selecting multiple dates on a calendar? This is the moment when the <a href="https://www.nngroup.com/articles/ten-usability-heuristics/">classic usability heuristics</a> come in handy, making it possible to evaluate solutions based on good practices and sort of a design consensus.Tools and services: sometimes, the solution to a problem doesn't have to be built from scratch by our team if there are viable options on the market. For example, recommending a customer support platform such as Zendesk to a client is a much more efficient solution than developing our own help center with live chat and a search engine. Folks from other teams can help a lot here since they're in touch with different products, services, and platforms.Depending on how refined the research is, it's interesting to present the results as a deliverable to the client. B2C clients love when I bring them competition benchmarks, because it tells them a bunch of things they already know, along with a few surprising insights, and gives them more confidence to make assertive decisions about the product.<h2 id="4-visual-ui-design">4. Visual/UI design</h2>After the user flow is approved by the client and the architecture is clear for the development team, I start working on high-fidelity prototypes. The fonts and buttons and pretty pictures. The shiny part of the design world that lured me into it, and turned out to be a very small piece of what I do.This step requires a lot of communication with the dev who will be allocated in the feature, as well as other front-end geeks. It's important to know if the visual elements and effects I'm proposing are easy to implement, if they're readily available on a component library, if there's a chance they'll break the entire website structure and such. The goal here is to have the highest impact on the product with the least effort. Once the UI for the new feature is validated with the team, we present it to the client, preferably in another design meeting (but if it's a tiny feature or a simple UI improvement it can be done quickly through Slack). The goals here are:Get feedback on visual design. Depending on the project, this moment is for minor tweaks or major rework. Some clients are way more detailed-oriented than others, and some features are much more about delight than functionality (when the focus is on acquiring new clients, for example). At this point, personal opinions, both mine and the client's, may want to hijack the design discussion, and I've been learning a lot about self-control and managing my ego on these situations. Here is where a good research and a thorough process really pay off. If I know the reasons behind every design choice I made, it gives strength to my arguments when clients start to wander on personal preferences.Define priority for development. As we approach the end of the design cycle for the feature, we need to know what's the schedule for implementing it. Our project manager tries not to let approved features sit in the backlog for too long, but it really depends on the client's strategy.<h2 id="5-design-specs">5. Design specs</h2>A great advantage of having design and development working together is the fact that our team can clear out any doubts about a new feature's UI and behavior with the designer, on the go. We're usually in the same room, a few feet apart.That said, we still need clean, well-documented design specs. It used to be a very time-consuming part of the process a few years ago, but today we have really cool software that picks up a layout from <a href="https://www.sketchapp.com">Sketch</a> or <a href="https://www.adobe.com/products/xd.html">Adobe XD</a> and breaks it down for developers, going as far as translating graphic elements into code snippets. At Vinta we use both XD native design specs feature and the <a href="https://zeplin.io">Zeplin</a> plugin for Sketch to handoff specs. Every layout gets its own link, that is conveniently attached to the Trello tasks for our team. For some features, we also add the user flow or a lo-fi prototype along with it.We're still working on building solid component libraries and <a href="https://designmodo.com/create-style-guides/">style guides</a> for our clients, which are proven to speed up the design process and enable developers to make quick UI adjustments without even needing a full-fledged layout. It's our next big goal and we're giving it a higher priority on the design roadmap of our projects.<h2 id="6-feature-review">6. Feature Review</h2>This is a small step but represents a huge improvement in efficiency. The Review and QA phase is traditionally when developers run tests to catch bugs and see if the new feature behaves well. It also used to be the moment when the client went through the user flow to check if it was built according to her specs, including front-end.When I introduced the design stage in Vinta's workflow, we picked up this front-end and user flow review from the client. Since they already approved the design earlier in the process, it's up to us to make sure the final result is pixel-perfect and the flow is functioning as it was specified.Centralizing the review process reduced the back-and-forth between our team and the clients, and made our workflow more agile, since the developers no longer have to wait for their feedback to make adjustments. It was also a nice display of trust from the client and an indication that we're going in the right direction.<h2 id="new-challenges">New challenges</h2>I like to think that we already achieved a lot in very little time, on this mission of bringing design into Vinta's workflow. Our teams now have more ownership of the product, because designers bring the features and roadmap discussion to a more strategic level. We understand the client's business in a holistic way and pay more attention to their needs and goals. That also makes us care more about the software we're building and think of new ways to improve it. But there's still a long way to go.Coming from a startup background, where I owned my product completely and had full access to my users, I miss being able to validate design concepts with real-world people before development, through online research and quick usability tests.The situation is pretty different here. Besides working remotely and not having our actual user base close by, our client's projects are confidential, so we don't have the liberty - yet - to call some people over, ask them to use the system and tell us what they think (one of the most insightful ways of running an usability test, in my opinion). But as we get closer to the decision-making process with the client, our next step is to get access to real users, have them test new features before the development phase and listen to them firsthand.Another important goal is to take more advantage of metrics, provide that intel to our clients and use it to validate our design decisions. Quantifying the value of a good design, a well-thought experience, is not a trivial task, but the right set of indicators is a powerful tool that we need to learn how to use well. I envision performance reviews as a new step in our workflow, in which we analyze the results of the piece of product we developed based on metrics and user feedback, and learn how we can improve on that, thus closing the agile development cycle. Our team already set metrics for the most recent new features, and we're ready to crunch some numbers and get insights.And finally, we need to scale our design workflow for larger teams. Vinta's design crew is growing, and it's important that we foster a good environment for collaborative work, healthy design critique, and feedback. On the technical side of things, we also need to find tools that enable two or more designers to work seamlessly on the same deliverables. We started testing a few versioning tools, but it's hard to say which one will stick. That said, we can learn a lot about versioning and forking projects from our dev colleagues.<figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/fc/22/fc22bfca-77ee-455f-88f6-c6a4d59b941b/flow-complete.png" class="kg-image" alt="alt text"><figcaption><a href="https://vinta-cms.s3.amazonaws.com/media/filer_public/fc/22/fc22bfca-77ee-455f-88f6-c6a4d59b941b/flow-complete.png">click here to see it on full-screen</a></figcaption></figure>Starting this journey, I've read quite a bit about <a href="https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux">lean UX</a>, as well as <a href="https://uxplanet.org/one-year-of-lean-ux-68027e5a7214">experiences</a> from other designers building new workflows in similar contexts. But what helped me the most was the good work environment. Inside Vinta, pretty much every tech lead and team member were fully onboard with what I was proposing. These amazing developers backed up every tough decision I had to bring to clients, were ready to answer my silly questions about products I didn't understand in the beginning and have been all-around great coworkers. Thank you all <3And special thanks to <a href="https://www.vinta.com.br/blog/author/robfilho/">Rob</a>, <a href="https://medium.com/@pjbacelar">Pedro</a> and <a href="https://goiabada.blog/@sergiofontes">Sérgio</a> for reviewing this post.Some readings that helped me a lot along the way:<ul><li><a href="https://uxplanet.org/the-evolution-of-ux-process-methodology-47f52557178b">Ian Armstrong - The Evolution of UX Process Methodology</a></li><li><a href="https://uxstudioteam.com/ux-blog/agile-design-process/">Ágnes Kiss - How to integrate design into your agile process?</a></li><li><a href="https://medium.com/user-interface-22/design-leadership-is-a-hugely-important-topic-these-days-e222836915d0">Jared Spool - How Designers Turn Into Design Leaders</a></li><li><a href="https://uxdesign.cc/why-design-thinking-is-failing-and-what-we-should-be-doing-differently-c8842f843b44">Lilian Ersoy - Why Design Thinking is failing and what we should be doing differently</a></li><li><a href="https://www.intercom.com/blog/how-to-hire-designers/">Paul Adams - How to hire designers</a></li><li><a href="https://medium.com/the-year-of-the-looking-glass/metrics-versus-experience-a9347d6b80b">Julie Zhuo - Metrics versus experience</a></li></ul>

Bringing design into an agile development workflow

Join the Tech Forward newsletter

Related articles

How We Roll Our Design Process

Fast enough? 9 tips for web page optimization

How to make sure your Celery Beat Tasks are working