Guest article written by Andrew Mottaz, Founder and CTO of Site9/ProtoShare
Taking a broad look the wireframing/ prototyping/ rapid development discussions that you find online, you see a large and growing list of how to handle visualization during your development process. There are proponents of the ‘only low-fidelity sketches’ school of web project planning, all the way through to the ‘build everything in real code from day one’ school of thought.
I attended a talk by a bay area VC who actually said that developers need to start thinking of iterations in terms of hours instead of days. Their product development process involved user testing paper prototypes and moving on to working code within 2 days. While I think that philosophy only applies to a small set of development tasks and product development processes, I think there is a big idea behind it. The big idea is this: Get people looking at and interacting with your ideas fast, do it often, and do it over and over again.
And this is the idea that I think can really drive improvements to development, better products, and make the entire development process easier, with less conflict and misunderstanding. Perhaps not surprisingly, this big idea is fundamental to our product ProtoShare, and it’s why I think developing ProtoShare reduces rework and misunderstandings so effectively.
So let’s start at the beginning: an idea. Whether it’s your own product, or work that a client wants done, every project starts with an idea – it may be a goal, like – I want to increase my ecommerce conversion by 50%, or I want people to visit my site every day instead of every month. Or it may be an idea to build a website or an app where the goal is implicit in the idea: let’s build a really great collaborative project management tool. So what’s the first thing you should do with the idea? Sketch.
When I say sketch, it can mean any number of things – whiteboard, paper and pen or any tool you have handy. I use ProtoShare for this, because we build it, and because I like to have my early sketches in digital form for when we’re creating more detailed mockups and prototypes. (I also can’t draw at all).
These sketches don’t need a lot of detail. Rough out your home page idea. Include text that describes what you want the content to achieve. Try to get your idea into a concrete form. And then get all of your stakeholders to look at it.
This is really your first ‘user test’. Granted, these aren’t “Real Users”, but when they look at the sketches, you will discover several things: First, do all of the stakeholders have a shared understanding about what you’re doing? Second, do the rough ideas you’re proposing meet the expectations of all of these stakeholders.
The next step is often wireframes or low-fidelity prototype designs. You can use these to refine the ideas you built in your sketches. I like to add some functionality or link wireframes together so that stakeholders and other users can actually start to experience, rather than just look at what you’ve built.
In fact, the real benefits of a prototype design at all stages of a project are that it lets your users and stakeholders experience what you’re working on. This can radically increase engagement, meaning you get better feedback, and everyone gets on the same page faster.
After wireframes, you can go into mockups, prototypes, or even testing of live code. One technique I’ve found really helpful is to build higher fidelity prototypes. You can increase the functional fidelity, adding pop-ups and other interactivity, and the design fidelity, starting to layer in the look and feel you want. Both of these activities can really up the stakeholder engagement, which in my opinion is one of the things that really can bog projects down. When stakeholders don’t engage with the early deliverables (whether they are spec docs, sketches, wireframes or alpha level products), you end up with lots of late-stage rework. All the stakeholders will completely engage 2 days before the project goes live. Your goal is to get everyone engaged in the process as early as possible, and keep them engaged throughout.
Another benefit of visualization is that you can start to engage your actual end-users as soon as you have anything to show them. Many are hesitant to get end-users involved in anything other than working code, but even from the earliest sketch phases, you will get valuable insights from your end users. I do agree that you get the best feedback from end users with higher-fidelity, so I like to use high-fidelity prototypes and/or working code for some late stage user tests.
But there is another vital function that end-user testing plays, and that is getting all of your stakeholders and teams on the same page. I’m an engineer, and I’ll happily argue the merits of a change, its internal logical consistency and whether it represents a best practice all day long. If you’ve ever tried to convince an engineer through argument alone, you know it’s next to fruitless. The same can go with any important stakeholder – executives, designers etc. The one thing I have seen that will immediately and fundamentally align every different stakeholder in a project is to watch a user struggle or succeed with your software or proposed solution. The end-user serves as a kind of neutral third party that can be used to aid the decision making process, and really get everyone in agreement.
So use visualization to take your ideas from the abstract to the concrete. Get end users involved as often as possible to make sure you’re moving in the right direction. In the end, you’ll greatly reduce development effort, thrash and rework, cut down on misunderstanding between various stakeholders, and ultimately end up with a product or site that meets your goals and serves your customers.
About the Author
Andrew Mottaz co-founded Site9 as an interactive agency in 1999. He led the company’s technology development, helping create and deploy a range of successful e-commerce sites. In 2006, after identifying much inefficiency and many pain points in the interactive development process, Andrew decided to address these inefficiencies with effective solutions, and Site9 transitioned into a software company. Since releasing ProtoShare in 2008, Andrew has been working, writing, and presenting on how companies can implement effective UX processes.