Benefits of an Iterative Design Feedback Process

In this week’s episode of The Secret Sauce, Senior Designer Ashley Cyborski discusses our iterative design feedback process and how this helps move designs forward to effectively meet our clients’ ideal results.

TRANSCRIPT

Allison Manley [AM]: Welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a short piece of advice to help your business run a little bit better.

I’m Allison Manley, an Account Manager here at Palantir, and today we’re talking with Ashley Cyborski about a good design iteration and feedback process.

Ashley Cyborski [AC]: Hi everyone,

My name is Ashley Cyborski and I’m a senior web designer here at Palantir. You may remember my other podcast about the benefits of designing in the browser. You should check that one out if you’re a web designer feeling hesitant about taking the leap to HTML and CSS.

Today, though, I want to talk about our design feedback process here at Palantir, because it is a bit different than traditional design processes.

I’d like to rewind and give you a bit of background. At Palantir we use agile methodologies during our development process. For anyone unfamiliar, agile is a 2 week cycle called a sprint where you prioritize work, complete those tasks, present the work to the client, and receive feedback which you can then incorporate into the next sprint. It is a process of continual improvement and collaboration. Our design feedback process came out of a desire to incorporate that same level of collaboration and continual improvement into the design phases of a project.

After a lot of thinking, and quite a bit of inspiration from a webinar by Dan Mall, we came up with a process that is iterative, but accommodates our clients’ needs.  The process isn’t perfect and we are continually working to improve it, but it is a huge improvement from where we were just two years ago.

The core principle of our design feedback process is iteration. Though this sounds pretty obvious, it is very different than the traditional design feedback and iteration cycle. In a traditional process you present your work, receive feedback, incorporate that feedback into the design that you had presented, and then re-present your work, around and around until the client decides to approve the design. And though that works quite well for print design, it is counter intuitive to web design, especially when paired with an iterative development process.

In our feedback process we often tell our clients to think about moving designs forward. At the start, we present 2 to 4 style tiles to the client. Then, we ask them to choose the “most correct” one to move forward with. The one they chose may not be perfect yet, but through iteration and with the proper input, we move the design closer and closer to that “ideal”.

In order to get there, we need that input. We ask our clients to provide feedback on the chosen style tile and the discarded ones. We prompt with questions like “What did you like about this design?”, “What don’t you like about this design?”, and most importantly, “Why?” Our goal is to understand our client’s thoughts and feelings, including what is inspiring them and what is concerning them.

We take all that feedback and the selected direction, and begin on the first static comp. We don’t spend our time iterating on the selected style tile.  At this point we repeat the process with static comps. The feedback received during the comp phase is worked into the prototype. From there on out, the prototyping process syncs up with the sprint cycle, and feedback on prototypes is defined and prioritized along with the remaining design tasks and incorporated on a sprint by sprint basis.

That was a lot of words to describe how we move the design process forward. You might ask, why don’t we work on one deliverable until it is “perfect” or close to perfect? Well there are a few driving factors.

First, our process becomes faster and more efficient because we don’t have to pause the project to work out small, inconsequential details that would otherwise resolve themselves in the future. The entire project doesn’t pause until we get it to some subjectively “perfect” state of design. This is important and unique to web design, because your design will appear on any number of machines, browsers, screen sizes, and with multiple variations of changing content over the course of its life. A website is a living, breathing, changing thing.

Second, we can adjust the course of our design as the project moves forward and develops. We aren’t stuck with a decision we made in week 1 of the project, when we learn something new in week 7.

Development prioritization can drive design prioritization and the design benefits from active and informed developer feedback and input. This benefits the designer, because we aren’t completing work that ultimately will not be implemented, and benefits our clients because they aren’t paying to design work that ultimately won’t be implemented.

Third, we get to the browser faster which benefits both the client and the project. I track some of these in a blog post about designing in the browser, but I’ll recap the main points here.

Clients tend to understand designs better once we get into the browser because they are more realistic and interactive which helps clients provide better, and more relevant feedback. In browser designs also foster more productive communication and collaboration with developers and reduce duplicated work. Additionally, designers have more control over the final, implemented design.

Finally, and possibly most important to the feedback process, it is easier to implement feedback and iterate on the design system in code than it is across multiple page comps. The feedback changes are instant, consistent, and more efficient.

Ultimately, this means that the client is able to provide more realistic and relevant feedback, which can be implemented and iterated on faster and more efficiently, all while the design process flexes and flows with development’s needs and prioritizations.

I think I’ve outlined a lot of the benefits of our forward moving design process, but I should caveat that we are still iterating on this process to make it even more efficient and effective.

One of the major gaps in this process right now is client education and buy in. It is often hard to convince a client, with little to no experience with web design, to adjust their preconceptions about the design approval process. It is also hard to get buy in, for example, that the homepage static comp does not have to be “perfect” in order to move onto the next deliverable. Clients fear that their feedback will be lost or forgotten or that it isn’t being taken seriously, when they do not see it implemented immediately. Clients often tend to be relatively uncomfortable moving forward with something that is not “Approved” or finalized for these exact reasons. One way we try to counteract that is with documentation, making sure we track and the requests changes and tickets.

It is up to the designer to communicate as best we can the benefits of this process to our clients upfront. I really believe that ultimately a client gets a better, more flexible end product when using this process.

I’d love to hear other’s experience with a similar process. Whether it is an issue you’ve run into and solved, or just with your own experience with a similar process as a client or designer. Leave a comment on this post or tweet to me @AshleyCyborski.

AM: Thanks for listening to this edition of The Secret Sauce. You can find more great tips on our brand spanking new website at palantir.net, and you can also find us on twitter @palantir.

Enjoy your day!