The Process and Progress of Agile Design
How to apply the Agile process to design projects.
In my first year working at Palantir as a Project Manager, I’ve learned a lot about the Agile process in regards to development. I had worked with it from a distance at my previous job, but this was my first experience working with it on a consistent and immersive basis. At a project management conference I attended last year, there was a panel discussion about the Agile development process. The presenter asked if anyone in the room had successfully applied the Agile process to the design portion of a project, and the room was silent.
We at Palantir had already been thinking a lot about how to make the design process more Agile, and were looking for opportunities to try it on a future project. Our design team has extensive HTML and CSS/Sass skills, which allow the design process to quickly move off of the whiteboard and into the browser. This, in turn, makes for a much easier transition to development, since our engineers can repurpose much of the work done during the design phase and run with it. It also allows for constant and close collaboration between the visual design and the backend structure, so we were excited to try to see how Agile we could go.
What is Agile design?
The original Agile manifesto states the following four values in developing software:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
At Palantir, we have long been designing in the browser (“working the software”). By nature, the design process already values collaboration and flexibility, and our modular design process was taking the flexibility even further. What was left was being able to integrate our teams more closely so we could interact more closely. One of our senior designers and technical leads sat down together to discuss how they’d approach a more Agile process, and worked out a system to try to execute a user story by designing and developing it in one sprint.
Needing the right circumstances
It’s clear that this process wouldn’t work for every client. But we had a client with whom we were able to try this method because we had the following set of circumstances:
- A small, nimble team of Palantir designers, front-end developers, and engineers that were able to work closely together
- A strong client product owner who was able to turn around decisions very quickly
- Very few levels of approvals within the client organization
- A healthy schedule of about four months
- An Minimum Viable Product (MVP) list that was well-defined upfront before work began
How we did it
Typically, the design process starts with high-level concepts, followed by wireframes and fleshed-out home page designs. Once the client chooses a direction, the design will be extended into landing pages and other interior pages. Throughout the process there are specific checkpoints with the client, usually followed by a waiting period as the client approves the design. All those dates must be scheduled in advance so presentation meetings can be arranged and put on everyone’s calendars.
Our senior designer on this project had another idea of mirroring what the development team was doing with Agile methodology: show progress, and get the progress approved, not necessarily the finished designs. After white-boarding, he wanted to handle the designs as biweekly sprints, where we would demonstrate progress on the weekly build and demo calls. During these demo calls he would show modular pieces of the design that would culminate in the finished design towards the end of the project.
So in short, the client would see pieces along the way which would ultimately come together as a cohesive design at the end. It also meant no need to schedule extra meetings, as the design demos would piggyback onto the development sprint ones. We started with design elements like typography, color palette and image styles, and moved quickly through some high-level homepage comps so they could get a sense of the overall design they would see at the end. These were quickly approved by the client.
As a team, we decided that it would be most advantageous to finalize the header and footer, so the developers could then get those built. This meant that the client would approve a header and footer without seeing what everything in the middle looked like. But due to our strong series of kickoff and discovery meetings, we nailed this pretty quickly, and gave the development team something to build right away. From there the content for the midsection of the home page was designed (which underwent many tweaks from the original comp), and some interior pages, always refining and adding modular pieces (sidebars, call-out boxes, etc). And because we create living style guides for all our projects now, the design system was well documented for easy and efficient translation into Drupal.
Avoiding land mines along the way
Since this was a new process for us, we knew there would potentially be some risks with intertwining design and development so closely, and we tried best to anticipate them. That said, we did encounter some risks during the course of the project:
- Guiding the process. Development is a more objective medium, since fewer people on the team are qualified to make adjustments to the code, and a feature either works or doesn’t. Design, on the other hand, is more subjective, and can often fall victim to conflicting opinions. So making sure that input on the visuals was limited and timeboxed was key. In order for the development team to not have to redo any work, we had to make sure everyone was focused on the branding and design goals that were outlined during our initial discovery phase, and not get derailed by the precise shade of blue.
- Seeing parts, not the whole. Since we were assembling the designs as we went along, the client would see just pieces of the design system upfront, and the final assembled home page towards the end – contrary to the expected way of showing more comprehensive designs at the start. We mitigated this by not only making sure the client was comfortable with trusting the process of seeing the compilation of all the design work later, but also providing a lot of value in what they did see upfront: separate design elements, followed by an overall rough concept of the final design, followed by a finished header, footer and side navigation. After each of these steps was approved in turn, we were able to quickly move on to the next one; ultimately leading up to the final comprehensive page design.
- Running out of time. Lastly, what if designs weren’t completed by the end of the final sprint? What if we simply ran out of time? The Agile philosophy is about prioritizing the features to be completed. So the mitigation was to make it clear to the client that they had to strike a balance between being able to make the needed edits but also make sure they didn’t hold up the launch date.
So...how did it go?
Overall the project was a success. We delivered almost exactly on budget, and the client has been actively using the site and is able to easily make continuous updates and additions. We also learned a lot about this new process along the way. From a project management perspective, scheduling was easier due to not having to coordinate additional meetings that were on a different schedule than the development team (though it was admittedly harder to track design rounds).
I also witnessed a much closer collaboration between our teams, and it was exciting to watch them work through the process of finding more advantageous ways to work together. Our technical team lead enjoyed being more sympatico with the designer, working on the same pieces at the same time, and having a lot of dialogue in the same physical space. Our designer thought that continuing to make decisions about markup and CSS during the prototyping phase and using a tool best suited for this experimentation (Jekyll) and iteration proved to be an asset for this project.
Additionally, while he thought the Agile approach to design is a good one, he felt that it didn’t work as well to develop and design at the same time. Instead, he felt we should stagger design before development started. That doesn’t necessarily mean development should have waited until design was done either. Instead, it meant we needed to create an environment where we didn’t step on each other’s toes. This also requires having a longer project schedule in order to make it work.
Can I do this for my project?
I had another project run simultaneously with this one where the design process was very different: it used a more traditional waterfall approach, where design was mainly completed before building began. This was due to the client having many levels of approvals to go through, and thus weren’t flexible enough to iterate with any great speed. So I was able to make a direct comparison as to how the processes ran. The advantage to running a project more Agile was the speed with which we could work, and the close integration of our team (which was also fantastic for general team-building).
That said, sometimes it’s simply not appropriate to do design in an Agile way. Larger organizations might need a week or more between design presentations in order to get approvals. They might have budgetary constraints that require projects to be done in distinct phases with little to no overlap. Another organization may have too short a time frame.
The biggest thing to consider when choosing a methodology is how involved they want to be in the process of building, since Agile design and development work best when the client is thoroughly engaged. To be clear, we don’t have the process perfected here yet either. Some questions we asked ourselves: how different was it from a waterfall project really? Was it a waterfall project simply organized into two week chunks? Was it the increased modularity that made it more Agile?
In the end, both the iteration and integration on this project was faster, and we’re excited to keep improving these steps with future projects. It’s still a work in progress however, and will continue to morph depending on the individual projects and client teams. If you want to try this for your next project, be open-minded and realistic in the beginning to determine what will work best for your organization from a financial, logistical, and personnel point of view. In the end, does it matter really if your process was waterfall vs Agile, or some combination of the two?
Any user looking at the site will never know the difference. As a Project Manager, I’m looking for a client who is not only happy that everything went smoothly during the project, but is also happy everything was within budget, worked aesthetically to meet their visual goals, and worked to meet their business goals at the end of the project.