Thoughts on Design and Agile

A perspective on how different facets of design fit best for different types of projects --thoughts, best practices, and insights.

“Design” vs. Theming

One major lesson over the years is that discovery and design work is significantly different than theming work (duh?). When you are doing both, you get to cheat a little, in that assumptions made during the design phase can pass on and be solved in the theming phase more smoothly. There are many moments in theming when you make small but important design decisions that add up to creating a holistic design. Being the “owner” of the visual design can bring a lot of benefits when you are also implementing that design if you have the skills to do it well. You can wait until the theming phase to solve more holistic visual design system challenges – seeing how different components interface together, and how if you change a margin in one place, you might also want to adjust it elsewhere to match. It means you don’t have to make as many comps because you can just interpret the few you have made and apply them to new interfaces. In some ways, you carry the design in your head and paint it on as you go. This has worked well when you are the sole designer/themer.

That said, I strongly believe that designers should not have to write production-ready front-end development code. There are many times over the past few years where I’ve wished to have a themer partner to pass designs to and collaborate with. This is heavy for context switching. So I do think it’s best for teams to think about discovery/design as different than theming, and acknowledge that this might not be best assigned to a single catch-all “designer” unicorn. (Talking about unicorns will have to wait for another post...)

The Design Process

For client work, major redesigns, and projects with a clear delivery date and hand-off, I strongly believe that a true discovery and design process is best approached in a waterfall way. You can chunk it up however you’d like and call it sprints, but I believe there is a natural order of operations when defining and designing.

The diagram below outlines how we approached major redesign projects coming through SWS:

 

In the first three phases of the process, you go through a waterfall approach to discovery, content architecture, and user experience. During this process, you want a tight feedback loop with the development team, to make sure what you are designing makes sense and is buildable.

After this first phase, there is a critical moment where you have your wireframes, content model, functionality specs defined, and you can create a functional backlog of development work. What’s important to note here is that a wireframe is an unprioritized backlog. Part of the nature of design deliverables is that it is hard for them to be agile by nature. If a block on a page is prioritized down in the backlog during the design process, but it was a prominent block on the structure of the page, the designer has to be available later in the agile process to address changes in a layout based on prioritization of features.  This is why it is important to pay due diligence in the discovery/design/define phase to make sure that at least the wireframe(s) captures the vision for the project completely, even if there might still be some hard choices ahead. It’s hard to make prioritization choices with half-baked requirements.

After client approval and prioritization of the backlog, you can dive into developing specific functionality and features, and you can start the visual design phase. In our process, you may note that the visual design phase overlaps with the start of development since for the most part, all you need to get started with development is a spec (and that’s what a wireframe and annotation are good for). The visual design then runs in a waterfall way with client revisions and approval on top of (or in parallel with) the agile development process.

After sign off on the visual design, you can start theming. Theming trails development, and can be managed in an agile way – as things get built, they get ready to be styled. And to what extent you can in advance, you can write up styles for components and core elements.

In the end, after development has finished, there is a design review phase, where you polish all the corners, discover bugs and minor changes and tie a bow on it.

Integrating waterfall design into agile development

I think the key to integrating a waterfall design process into an agile development shop is collaborating with a rockstar project manager to anticipate and plan in advance the time, space, and resources to allow for the discovery/design process to play out so that we know we are building the right thing and solving the right problems. In a way, this has more to do with managing the backlog than it has to do with the specific order of tasks.

Agile in its best form allows teams to prioritize work, understand its size and value, and make smart decisions about what to do next. The tricky part is that discovery and design define the size of the work, and is often an unknown variable in the process as you build requirements with a client.

Design in Agile Feature Development

Although I feel strongly that there is a natural order of operations for discovery and design in order to come up with clear requirements for a project, there is absolutely a place for design to live in agile feature development, where you have ongoing, iterative, continuous improvement product work.

The diagram below captures how a typical feature design and development process looks:

 

In some ways, this is the miniature version of the first diagram. I still believe there is discovery/design work that needs to happen before development starts, but I believe this has to be done in a tight loop with the developers to ensure viability.

The more iterative and agile way to work on feature development is to create tight feedback loops between designer and developer throughout the entire process. In the first half, the loop ensures that the designer is creating something that is buildable and makes sense. In the development phase, the developer should be leaning on the designer for QA and feedback on what has been developed. In the end, as the feature is being styled, there is often some back and forth between themer and developer to make sure that what was created is most efficient for theming, and vice versa.

Because there are basically three phases to this process (design, development, theming), you can imagine that each phase might fall into a sprint, and in this way, you can have overlapping sprint cycles, where one sprint the designer is working on defining the feature that will be built in the future sprint. (see figure 3 below)

 

While this process helps you fit feature design and development into agile sprints, I am still not sure if this isn’t just a mini-waterfall process, dropped into an agile schedule. What this does do well is give teams a tighter feedback loop by chunking the work into manageable pieces and engaging the team in collaborating.

When it doesn’t work

When we have tried to apply this more iterative cycle to complex client work, we have faced some challenges. When you break discovery and design of individual components down and out of the context of the bigger picture, it is harder for stakeholders to communicate requirements and see how the work fits with the rest of the project.

Another situation where this process becomes challenging is when the feature or component that it’s focused on is too big or too undefined. In this scenario, you have to step back and spend more time doing careful research and discovery, getting input from the right stakeholders to make sure you are coming up with the right solution. In this scenario, it is very possible that design and discovery may take much longer than a typical iterative sprint cycle, and it’s hard when you are basically saying, “Hey developers, not sure when we’re going to know what you’re building.” The solution to this is more advanced planning, more lead time, and setting clear expectations around new feature requests, and clear guidelines for decision making on what is in-scope vs. out of scope for whatever version you are planning for.

In conclusion…

Evolving your process is… a process. At SWS we’ve focused on having an open dialogue about our process in an ongoing way. Having debriefs and retrospectives helps us grow our process over time, try new things, and reflect on what didn’t go so well. As you can see, “Design” is a big bucket, and encapsulates a lot.