Iterate Iterate Iterate Iterate

Silos Are for Grain: Part 2 of 5

In case you’re just now joining us, let’s do a quick recap from last month’s article. Before you put any pen to paper, marker to whiteboard, or finger to mouse, you should be talking to users. You should be gathering information and then coming to a consensus with the product managers and engineers about the nature of the problem before you ever design a single pixel.

You can read the entire article if you’d like here.

Now to the matter at hand.

Kill Your Darlings

Four or five years ago there was a very in-vogue design catchphrase that I felt I saw hanging in every agency’s walls and in every product design team’s cubicle. I saw it pepper designer backpacks with pins and cover Macbook Pros with stickers. It stated simply: “Kill your darlings”.

It’s actually referencing a famous quote by Arthur Quiller-Couch,

• “Murder your darlings.”

That sentiment was often repurposed by the Master of Horror himself, as Stephen King was often quoted saying,

• “[K]ill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.”

It refers to the writing process and the need to eliminate our favorite creations if they don’t fit into the greater narrative.

On a fundamental level, I agree with this advice. In addition to writing, it speaks to one of the core job requirements of being a designer — the need to emotionally separate ourselves from our designs. I do believe however that this practice is flawed.

And Bill Murray has the key to fixing it.

Phil Connors Got It Right

One thing that needs to be pointed out from the get-go is that the character Phil Connors, from the cult classic film Groundhog Day, didn’t get it right immediately. He was put in a fantastical position where he effectively had to “kill his darlings” every day.

Any work he did during that day with relationships, career aspirations, or any other interactions with those around him, he would lose at the end of every day. He spent a lot of time doing some fairly unproductive things — including letting a groundhog drive him off a cliff and into a rock quarry. But then, in his madness, he kind of figured it out.

Phil spent day after day after day finding the optimal path. That optimal path would save the kid from breaking his arm from falling from the tree, save another person from choking, while also refining skills and learning more about those who immediately around him. Then he would reset again the next day, with the same set of problems, but with a little more knowledgeable a little more context. Bit by bit, he’d refine his path.

So while it’s important to “kill your darlings” in design, you need make sure to frame them and put them on your metaphorical design fireplace mantel. It will help you to work through gradual refinements, and eventually tune into that optimal path that will lead to the overall success of a design.

Productive Iteration

All of this is representative of how we, as digital product designers, can use iteration to quickly optimize and narrow in on the problem we need to solve. My first introduction to iteration was from my brother who works as an art director in the advertising world.

I wanted to design a logo for my own personal brand as I was starting to apply for UX/UI jobs, and I worked with him to come up with a brand identity for myself. His suggestion was to “iterate” like crazy. In the context of that conversation, he meant to brainstorm and draw as many ideas as possible until I found a keeper.

While this is a great exercise to come up with a logo, it doesn’t work quite as well in the context of trying to develop a narrative for 50+ screens that need to mocked-up. Even still, I see designers who can fall into this way of thinking — that iteration is a series of different approaches to the same problem.

And while there is a place for that type of brainstorming, the refinement, or Bill Murray step as we’ll call it, is the critical piece to getting the desired result. It’s the micro-tweaks to the workflow that get us to something that is elegant and intuitive.

You’re Wrong

So you’ve done your due diligence. You’ve talked to users, you’ve collaborated cross-functionally, and you’ve iterated effectively.

Here’s the kicker.

This is the time you have to be open to being completely and unequivocally wrong. It’s time to meet again with your engineers and your product managers. You need to talk through your proposed design with them and chances are that even though you just came to a consensus from talking to users, there are going to be some fundamental changes you need to make. Maybe your brilliant idea for how to solve the problem is impossible within the currently technology stack. Perhaps an aspect of your design will have patent infringement problems. It is even very likely you just forgot to take something under consideration that is obvious to your developers or product managers. Now is the time you have to be most willing to kill your darlings.

A quick note on the fidelity of those iterations: There are some schools of thought out there that there are some hard and fast rules around what level of fidelity you should be showing to cross-functional teams. Do you show low-fidelity that could be drawings on a white board, or gray scale boxes draw in Adobe XD? Do you show medium-fidelity that could be grey scale nearly pixel perfect designs? Or do you show high-fidelity designs that are already to the visual level where they could be handed over to the dev team?

It depends.

It all depends on your the type of relationship you have with your cross-functional teams. Since that relationship has been a central focus of the Adobe Analytics team for more than three years, we are to the point where we can go straight to hi-fidelity with the understanding that this is a first stab. Since we’re drawing from a pre-existing UI library for the visual elements, it’s quicker for us to jump straight to high fidelity just using those elements from the style sheet.

If your relationship isn’t as well-defined or mature, you probably want to stick to wireframes and whiteboard drawings so that the fidelity of the mocks match the fidelity of your thought process. It’s all about managing expectations and keeping everyone involved in every step of the process.

At the end of all of this you should have a narrative with (eventually) hi-fidelity mocks that are representative of the problem that you discovered in talking to users. That narrative and corresponding mocks should have consensus across your product team including the engineers and product managers. At this point you’re finally ready for some user-testing. Let’s chat about that next month.