We do this all the time in life. We start with a broad idea and make it more specific. It’s natural. It’s normal. It’s healthy.

“Want to go out? Food or a movie? What type of food? Which restaurant? What night? What time? Where will we meet? What should we order? etc.”

And yet, when we have larger teams working on software projects, we often try to plan things out in advance in way too much detail. Now, we know that many teams have taken a much more agile approach over the past few years. But many teams haven’t. And it’s usually the larger tech teams, where lots of people are working on a project, and managers have been put in place that suffer from this disease.

On larger projects communication gets harder. And so people try to formalize communication and get more disciplined about change. Because change without proper communication can cause work to be thrown away and time to be wasted. And yet, When you make the process more brittle, the process itself tends to fight against change and agility. And change is good, even when it causes previous work to be thrown away. Sometimes, especially when it causes previous work to be thrown away. (Cue the masses cheering for throwing bad stuff away.)

We can already hear the objections: “but this is change for change’s sake”? This is the response people give when they don’t agree with the reason for the proposed change or with the change itself. (And honestly, sometimes change for change’s sake is not a terrible thing given our customer’s short attention spans and tendency to get bored.) But that said, if you’re on a team that’s optimized around leadership and trust, then change should be welcomed when it comes from a trusted colleague.

So how do we iterate and make change in a software development process? We call it, the loop.

Think of a big concentric circles, or even better, a spiral, where with each loop we get closer to the center… we get closer to detail and ultimately to reality. At the outside of the spiral we’re just talking and brainstorming. Then we’re sketching on whiteboards. Then we’re drawing wireframes — maybe with little hints about how the software should function in certain cases. In the meantime, maybe we’re experimenting with visual collages to come up with an aesthetic. We narrow it down to one visual direction. Then we’re drawing a set of visual elements that look like user interface elements. We’re experimenting with color. At some point the visual language feels coherent, and the wireframes are telling a story of the software’s interaction. Next, we’re applying the visual language to some subset of the wireframes – they look like real user interface screens. We know how the software will feel. In the meantime, the engineers have started coding. Maybe they’ve focused exclusively on the back end. Or maybe they’ve built the front end based on the wireframes without a visual treatment knowing they’ll apply that on top once it’s done. After all, the wireframes should have accurately defined 90% of the elements on screen even though their presentation isn’t decided yet. By this time, the detailed mockups (visual language applied to the wireframes) and the code are ready to engage in a full on slow dance. Holding each other close, tight, and in rhythm. The coders are now implementing the comps in code. And as time marches forward, and we get closer to sharing that software experience with the world… the software is coming to life. It was in our heads, and now it’s living and breathing and being touched and succeeding and sometimes failing. And we’re tweaking it, and changing it, and pinching here, and tucking there. It’s not quite what we imagined back on the whiteboard, but it’s somehow, even better. Each loop gets clearer, sharper, and has progressively more detail until the code itself is the sharpest picture that can exist of the experience because it IS the experience.

That’s what happens. And when everyone is focused, and excited, it’s like magic.

Celebrate the fact that you’re making software and not a skyscraper. It’s the only reason you get to take shortcuts like this.

And these shortcuts, the things that didn’t happen, in some ways they are the most critical elements to making this work:

• There were no written “specs”. The wireframes and visual design exercise was the closest thing there were to specs. Engineers work directly with user experience designers when there’s not enough detail. Either the engineer has enough experience to fill in any missing details in the right way, or the engineer and the designer work it out on the whiteboard as the engineer codes. There are also no testers complaining about the lack of specs. This is because the engineers are writing their own tests. The fewer people that work on a part of the product, the fewer people need to know how it works and what the intentions are for the behavior. We’ve worked on enormous projects where there were detailed specs, meant to be updated with every single change. I’ll tell you now… other than possibly in rare cases in software written for the Defense Department, THIS NEVER HAPPENS. The specs never get updated with every detail. And if they’re off by a little but, they might as well not exist at that point. Dream all you want, it won’t happen.
• Of the spec-like things that were created — wireframes, etc., nobody went back and updated them when changes were made in later stages. Once you agree on a stage that it feels right, the team moves forward. Never backwards. Whatever stage you’re in becomes the spec. And finally, the code is the spec. It’s the living breathing document that dictates reality. Not some piece of paper, or a sketch.
• Everyone understood that in the early loops there were lots of details not covered. And they understood this because they were details that could be determined later. For example: the wireframes DO need to detail the global organization of the app’s functionality and what affordances a user will use to switch between those major areas. But the wireframes DO NOT need to detail what happens when a user types in the wrong password. We know what happens. They get an error. Is there room for improvement in the password error experience? Sometimes. At some point do an engineer and a designer need to collaborate to design and execute that experience? Yes. Can that be done in a sidecar fashion? Yes. You may ask, how do you know which items are important, and which aren’t in terms of when they need to be defined in the process? Well, the worst answer we could give is: experienced software creators just know. A better answer is this: for situations where there are tried and true solutions, for situations where the design is encapsulated in the experience and doesn’t affect a bunch of other areas, for situations where we’re not trying to make this a signature moment of the experience: for these situations, they can probably be deferred to later in the process without much of a ripple effect. We’re sorry this answer is so vague. But those of you who’ve made software before know this.

But the big question is why? Why do are the above elements NOT part of the iterative process?

The race to create a great user experience, to have a team be in sync about creating something wonderful and define the right details at the right point in the process is a delicate balance. We don’t live in a world of unlimited resources. (And even if we did it would only paralyze us from making anything anyway.) We also don’t live in a world where people love debating tiny details that should be trusted to small groups. We live in a world where these projects need to exist in a reasonable time frame with quality and distinctiveness. And you must eliminate some of these brittle and constraining tendencies in large project software development in order to make something great. Otherwise you end up with something mediocre delivered in twice the time. And nobody wants that. Not even the government.