The Basic Iterative Process

Everyone’s project is unique. There’s always something that sets a project apart from the rest of its cousins. But no matter what makes a project different, there is one thing that makes them all the same: the prototype cycle.

No idea comes out fully formed. It’s usually a plucky, sloppy mess with a good heart and a better drive to succeed. But it’s still not there yet. That’s why, whenever you consider a new startup or new feature, that you exercise patience first. Because you’re going to want to make it, show it, and then learn.

This will happen dozens if not hundreds of times before a project is considered done. Remember: it’s always better to release half an app than a half-assed app.

MAKE IT

This is probably the easiest part to think about. You just get it done. This can be your own rough outline of the project, a proposal to a team, or any number of steps in the development process. The point is that you’re trying to bring it to a sharable checkpoint.

I mean to say that you’ve reached the front of a waterfall moment. To those of you who cringe at that terminology, I suggest you embrace it for what it represents: a checkpoint on your way to completing your project. Treat it like a spot where you can turn around and fix things. The first steps you take past these waterfall moments make backpedaling a lot harder.

For PXP that means sketches, wireframes, proofs of concept, all the way up to finished alpha and beta iterations of your product. The important step is making it and getting it to a moment where you can show people.

SHOW IT

Once you’ve got something, you need to get more eyes and fingers on it. Treat it like a new baby in a Spartan village. Everyone has to see the new warrior -- and it MUST be judged.

Now, showing off anything that you’ve either made or backed can be terrifying precisely because it will be judged. It’s a vulnerable sensation knowing that effort you’ve put into a thing might not be good enough to some people. Maybe it’s off-base or confusing -- or worse, boring. But you’ve got to find that out and it’s important to find it out before you’ve built a whole house around it.

PXP has a throw-it-in-the-deep-end mantra about this. Not only do we want our other developers getting eyes on it -- we need users to see it too. We’ll throw it to our writers, our graphics guys, or folks outside of PXP just to get a different take. They won’t be focused on the architecture or the hard work that might have gone into it. They’ll be as impartial as we can hope and if a design looks ugly or feels clunky to them, well...we need to learn from that.

LEARN FROM IT

After showing it off, you’ve probably gotten some notes. People might have told you that it doesn’t make sense or maybe it looks awkward. Your project hasn’t measured up and that’s ok! It’s important to remember that whatever you made, whatever you showed, it’s ok if it needs to be worked on.

You probably also have a lot of interesting compliments. Maybe some you were expecting -- ideally many that you weren’t. This helps guide us because once you’ve learned what works and what really doesn’t we can hop back to the top of this list to make a new one.

At PXP, this is our favorite step. My developers have come to love the puzzle solving that comes out of it. We have a product, it didn’t work out, and we have a few clues as to why. Now my team has a mystery to solve.

So what does that new iteration look like to fix these things? It takes collaboration, problem solving, and a fervent desire to make, show, and learn again. And maybe next time there will be more compliments and less problems. Eventually we’ll get to the right point to move forward.

But the most efficient way to get your project to an admirable state is by working out those kinks with the prototype cycle within those waterfall moments. Over and over and over again.

Free Website Audit

We will send you the report from our audit findings for free

We'll never share your email with anyone else.