Header logo
Free Consultation

Web Design & Development Process: Part 7 - Immersive Demonstration

person presenting

Lucky number 7! I hope that’s how you feel anyways. There’s always the chance you are at this point in a real trainwreck of a project and are looking for salvation. Hopefully instead you’re just doing diligent research months before the next project begins to best equip yourself. Either way, let’s dig in. Here’s what’s come before:

So what do we mean by Immersive Demonstration?

Less talk - more see, feel and touch

Despite the fact that justifiable frustrations that may arise towards the end of a project due to someone not remembering that what you built is, in fact, exactly what they asked for, it’s undoubtedly true that it’s quite hard to “talk” through all the requirements of a project and assume everyone in the room both interprets and understands everything being said in the same way. Fill a room with the smartest engineers you know, plan a big project, and by the end of the build you’ll still feel like you played an expensive game of telephone. It’s just too hard to simply talk about this stuff, which is why we have mockups and wireframes and things, but it can’t stop there. We’ve got to get the clients/users/stakeholders in there playing with things toward the end of the project (at the latest) so that they can see, feel and touch what they asked for and confirm that it actually feels right. It’s not just about who is right or wrong or who has the best memory - it’s about making sure they’re happy with the end result.

So this means walkthroughs and demo videos and staging sites and whatever else it takes to get your client very tangible ways to experience what you’re giving them because that experience is a significant component of what they’re going to care about after all is said and done. IT people and developers will work it out when form validation fails or a remote sync doesn’t happen when expected - and those things are certainly important - but overall client happiness necessarily involves them saying “yeah, this is what I wanted/needed and I’m glad I bought it.” You’ll never get there just arguing over who asked for what in meetings or telling yourself you’re doing a great job. You also have to make sure that go live isn’t the time everyone on the side of the checkbook realizes that what you just made isn’t quite right.

When you do talk, teach

Everything above aside, there is a hard reality that all the stakeholders and users involved are going to have a hard time having clarity on all dimensions of a project. It’s not what they do all day - it’s what you do. It’s not likely their profession either. They are likely experts in their field of publishing or advertising or commerce, but you’re the expert in web presence and sound software. We’ve learned to recognize the difference over the years and it’s caused us to essentially learn to give our clients a break. We have to consider that the client might not be as deeply embedded in the project as we are and that can lead to some gaps in understanding. Those gaps might cause some requests that don't quite line up with the original requirements or the current state of things, but that's where we can provide clarity.

Education is key.

Remind them why you’re going this way and not that. Document key decisions and send it around for confirmation. Show them the risks of going the other direction. Take the extra time to demonstrate why a particular integration piece is necessarily expensive and requires extra layers of security and testing and give them the chance to come closer to your understanding. And not without significance is also our own willingness to learn more about their own industry and processes to make sure we aren’t operating under false assumptions or misaligned priorities. At the end of the day, if you care about the client relationship you should care about understanding, not just delivery, because that’s only going to help everyone long term. If they know what they’re getting, they’re more invested, can make better decisions, and will take more ownership than if they just walk away with this fuzzy sense of “boy, that was expensive” and then begin the endless cycle of “why does it do this?” after release. Uck.


We’re getting near the end now! Let’s make that a good thing. It’s time next to talk about priorities again, because, well - they still matter.

NEXT UP: Web Design & Development Process: Part 8 - Decisive Reprioritization


Clint Randall

Recent Posts

More Blogs