Over the past three years, I have been the sole designer with Stanford Web Services. I like to think that I’ve levelled up the rest of the team to embody user experience best practices and approaches to everything we do, though the reality is that I’ve had to wear many hats: user experience designer, content strategist, visual designer, themer… As our team has grown, this role I’ve played has grown as well, and it’s given me a perspective on how different facets of design fit best for different types of projects. In this post, I want to share some thoughts, best practices, and insights.
“Design” vs. Theming
One of my major lessons over the years is that discovery and design work is significantly different than theming work (duh?). When you are doing both (as I have been), 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 to new interfaces. In some ways, you carry the design in your head and paint it on as you go. This has worked well for me as 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. Instead I’ve just had themer-me to lean on. 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.
In the diagram below, I outline how I have 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 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). 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.
At 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 it’s size and value, and make smart decisions about what to do next. The tricky part is that discovery and design defines 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.
In the diagram below, I try to capture 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 insures 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. At 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.
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. How does your team approach integrating design into an agile process (or not)?
I would love to hear your perspective! Please share your thoughts in the comments below and let’s have a conversation.
Accessible Long Descriptions for Diagrams
Figure 1: Waterfall Redesign with Agile Development
From left to right: The first section shows a discovery phase, which includes requirements, research (data and qualitative), personas, and conversation with developer on “What are our development constraints and strategy?” In this phase you are figuring out “What is this?” and it requires a client sign off that might have some back and forth.
The second section shows a content architecture phase, which includes content model (e.g. taxonomy), information architecture, testing IA, and conversations with developer on “Does this make sense for development?” This phase requires a client sign off that might have some back and forth.
The third section shows a user experience phase, which includes UX flow, wireframes (or interactive prototype), usability testing, and conversations with developer on “Is the design buildable?” This phase requires a client sign off that might have some back and forth.
In the second and third phases you are figuring out “How is it structured and how does it work?”
After the third phase you now have enough information to build a development backlog which kicks of an agile development process.
Parallel to development, you have a visual design phase (phase four), which includes style tiles, high-fidelity comps (and accessibility testing), and style guide. This phase requires a client sign off that often will have several iterations and much back and forth.
After sign off on visual design, you can start theming the site. Theming can be done in an agile way, trailing on development. As a feature is developed, you can start to theme it. This process includes QA (is what was build correct, and ready for styling?), styling, testing, and merging the code back into the feature.
There is a point at which enough has been developed that the client can start entering content. This often results as a back and forth around development and design.
The final phase is a design review/QA phase, which includes design QA, “polish” of final styles, testing (responsive, cross-browser, accessibility), and in this phase you often work back and forth with a developer until launch.
Figure 2: Agile Feature Design and Development
From left to right: The first phase is discovery, which includes requirements and research (data and qualitative), and conversation with developer on “What are our development constraints and strategy?”
The second phase is design, which includes UX flow, wireframes (or interactive prototype), usability testing, high-fidelity comps, development specs, and conversations with developer on “Is the design buildable?”
Then development happens.
The last phase is theming, which includes QA (is what was build correct, and ready for styling?), styling, and testing (responsive, cross-browser, accessibility), and merging the code back into the feature.
Figure 3: Agile Feature Design and Development Sprint Cycles
This diagram shows three example features and the way that the work on these features lays out over five sprint cycles. In sprint one, you may be doing design and discovery for feature one. In sprint two, you may start development on feature one, and start design and discovery on feature two. In sprint three you may continue development on feature one, start development on feature two, and start design and discovery on feature three. In sprint four, you may start theming on feature one, theming on feature two, and development on feature three. In sprint five, you may finish feature one, continue theming feature two, and finish theming on feature three. This shows can you might plan for discovery/design to take place the sprint before development, and how these might play out.