In Digital Development the Only Constant is Change

Small Change-1
The most important thing I have learned after developing interactive initiatives for over 15 years is projects change during the development life-cycle.

The specifics of the idea pitched evolve before the launch. The information architecture gets modified after the strategy team defines it. The wireframes adjust when the content is applied. The design gets tweaked after the comps were approved. The basic usability gets revised before, during and after the build is complete. And lastly, there is always the chance your client’s objectives may evolve during the project which might change everything.

Let’s face it, if you are going to be in the interactive marketing field, change isn’t an “if” it is a “when”.

Now I know what some of you might be thinking right now, “if a project is well thought out and you have the right people in place, you can limit the amount of change.” I totally agree. Good clients, designers, strategists, account managers and developers can be amazing at limiting the amount of change a project might incur, but even the most skilled professionals face unforeseen issues beyond their control which result in change. But nine times out of ten change happens because things that looked great in wireframes, sketches, comps and storyboards just don’t work the way we thought when we give them life and put them in front of real consumers.

So the big question isn’t “how do I avoid unwanted change during the project life-cycle?” But rather, “how do I prepare myself and my team for the likelihood of project evolution?”

The simple answer is work quickly, think collaboratively and test often.

At the beginning of any project, the goal should be to create quickly create and demonstrate your ideas so others can weigh in and help without the fear of change. If you spend a couple of hours working up a wireframe, storyboard or design comp, you are more open to suggestions than if you would have spent three days or more. By rapidly executing your thinking, you give yourself time to show others, get feedback and make changes because it’s expected.

The same thinking should be brought forward with functional prototyping. If you quickly make your ideas tangible, you can show others how things will work and test to see if theories in the IA, wireframing and comp phases will hold up to basic usability. Once again, the faster you get this done (and keep in mind, you should do as much as is necessary to accurately test your ideas) the more open you and your team will be to recommendations to make it better.

Because we create user-centric experiences, we must always be open to the idea that there might be ways to improve our end product. Changes can come at any point in the life-cycle. And take it from me, if you would like to maintain your love of the game, don’t look for ways to eliminate change— adjust your process to welcome and accomodate the disruption.

Image Credit: Rodney White