A Framework For Considering Process - Responsive Process - Responsive Web Design, Part 1 (2015)

Responsive Web Design, Part 1 (2015)

Responsive Process

A Framework For Considering Process

OUR PROCESS IS ALWAYS FIGHTING FOR ITS LIFE

One thing that amazes me about most presentations or writing on process is how confident the folks sharing seem to be. Maybe we’re the outlier, but our process is always fighting for its life. If a new way of working comes along, we’ll try it. If we think there’s even a hint of a better way to do something, we’re going to dig around trying to uncover it. This is just how we’re wired. I get the sense that a lot of you are wired this way, too.

Let’s agree that our process is never complete.

SHIFT AWAY FROM LINEAR HAND-OFFS

Most in the industry agree that we have to stop throwing deliverables over the wall. Instead, many are thinking about how to reorganize their teams in hopes that having the right people involved for the duration of the project will increase teammate empathy and raise the bar for everyone. Trent Walton describes this eloquently in his post called “Reorganization16.” In it, he relates that the structure of your team often constrains the kind of process you can use and encourages us to consider smaller cross-discipline teams. We’ve seen this to be true and take a very similar approach. Truthfully, our past linear processes have probably always been a bit inefficient. I believe responsive web design has only made that inefficiency much more obvious17; tackling responsive work has led me to conversations with our clients around their organizational structure — more evidence that RWD really is a catalyst for organizational change.

We need to involve more disciplines for more of the project. I like to think about this as spiraling through a project18 with our eyes firmly focused on the end product, on the one deliverable. With each spiral through, we involve all disciplines, and we gain more clarity at all decision points. The concept is simple: allow the entire team to play a role throughout the duration of a project. In other words, recognize and embrace the impact that making changes in one area of a project has on the others.

My team and I landed on this idea (spiraling through a project) because of our interactions with a business mentor of mine. His name is Geoff, and he’s a very sharp guy. He’s been the CFO of some pretty large organizations and has made a career out of helping visionary leaders get a grasp on their company’s financials.

When we first met with Geoff, we were in crisis mode. We had a major challenge before us, one that neither my partners nor I knew how to address. Geoff sat us all down and asked us to “begin with the end in mind.” He wanted us to explain what it would look like after we made it through the difficult times ahead. He wanted us to define success for this time in our company’s life. As we continued to meet with Geoff, I started to get frustrated. Each time we sat down, I hoped he would give us the advice we needed to start to solve the problem we were facing. Instead, he continually asked more and more questions. This went on for several weeks, and it was a difficult time for me.

I will never forget the meeting I had with Geoff and my partners where it all started to make sense. Our meeting began like all the others; we went through our current understanding of the problem before us and took some time sharing any new insight we had gained. Only this time, each of us started to see the solution emerging. It wasn’t perfectly clear, but it began to come into focus. Of the three options we were considering, one began to look much more appealing than the others. What we’d learned over the past months unmistakably led us to the best option to address the problem we were facing.

This lesson has been invaluable for me. What it taught me is that a linear process requires us to make decisions before we have all the information. How could we possibly know everything we need to know to create a set of wireframes without considering the visual design? How could we perfect the interface design without experimenting with some front-end code? When we act like it’s possible to start with the content, then do some user experience design, then do some user interface design, and so on, we ignore the impact that each of these deliverables has on the others. Instead, we need to allow them to inform each other. We need to give them room to breathe, to adjust, and to use what was learned from the project to carry them forward.

This is precisely the “spiraling” process that Geoff was pushing us through. Those weeks of asking questions were informing our understanding of the problem. Instead of making a decision (approving a UI design) and moving on as if it would never change (OK, front-end dev, go code this design), Geoff forced us to recognize that we didn’t have all the information we needed to make the best decision. Geoff wanted us to wait until the “last responsible moment” to decide.

I’ve tried to translate this idea of spiraling to what we do every day, and I’ve landed on a visualization like this:

A “One Deliverable” workflow, where the focus remains on the end-product
A “One Deliverable” workflow, where the focus remains on the end-product.

Please put your own disciplines into the slices of pie above — the image is simplified to illustrate the approach. It’s important to note that those dots are not deliverables in the traditional sense. They represent opportunities for you to sit down with your client and review your progress toward the “one deliverable.” This means: stop refining deliverables for fear of disappointing your client. It’s terribly inefficient to make your wireframes look beautiful in Illustrator when a sketch on a whiteboard will do. We’ve even stopped calling them deliverables and started calling them updates.

This kind of workflow is flexible enough to use on any kind of project because you can simply swap out the types of disciplines that are needed for the project. The ceremony around the process can be made more rigid or more improvisational depending on the experience of the people involved. The key is to make sure all of the people are involved.

This approach delays decisions until you have the right information. It recognizes that decisions made by one discipline will undoubtedly affect the others. It opens the conversation to the team and requires buy-in from all involved. It’s less formal but more efficient. It’s less predictable, but I believe it has the potential to deliver a much better product.

Let’s agree that we need to seek out multidisciplinary contribution.

EFFICIENCY IS KEY

If we had all the time in the world, we wouldn’t have to worry about our process — we could just try stuff until we stumbled on a great idea. You and I both know this isn’t the case.

A lot of the adjustments we make to our process at Sparkbox are because we’re looking for a faster way to accomplish something. The promise of increased speed is also how we earn opportunities to work with some very talented internal teams at bigger customers. Everyone is looking for efficiency gains.

Let’s agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efficient. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.