So many web projects fail.
There are high profile examples, like the massive cost of the healthcare.gov website, but it happens to smaller sites just as much. They go over budget and miss deadlines. Even when a project does hit its targets, it often fails to deliver a website that lives up to its potential.
Believe it or not, it is rare for this to happen because of incompetence. Most of the time the teams working on these projects know what they’re doing. The problem is that circumstances constrain the way they work. They are limited by an organizational mindset regarding how projects should be run.
You might also like: Designing With the User's Context in Mind.
How clients expect projects to happen
To illustrate the problem, let's consider how something like a factory gets built. The process begins with somebody in senior management deciding the new plant is necessary. Somebody is assigned the job for making it happen and consults widely to make sure there is a complete understanding of what is required. The project manager then turns this into a specification that is put out to tender, and a supplier is ultimately selected. Plans are drawn up and production begins. At this point, scope creep is the enemy until the project is complete, when management reassigns resources to other projects.
A traditional project process makes perfect sense when building a factory. That is because the cost of raw materials is high. Once you start building, the cost of changing direction is enormous. That means scope creep is the enemy, and your specification has to be as good as possible before you start. The price of mistakes is high.
You might also like: Using JQuery Image Zoom and JavaScript Zoom for Product Images on Shopify.
Why digital projects are different
But what if that wasn’t the case? What if you could reconfigure the factory at any time quickly and inexpensively? What if you also had real-time data on how productive the plant was, so that you could adjust things as you went along to improve performance continually?
In such a scenario you wouldn’t bother doing broad consultation or create a detailed specification. Instead, you would just start building and adapt as you went along. Neither would there be a definitive end to the project. You would keep tweaking and improving based on the data you were getting.
That is the reality of digital projects. The raw materials of websites are free. You only pay for labor. You also get unprecedented amounts of data on how people are interacting with your site. You no longer need to build a product and hope people love it. Instead, you can prototype and trial.
Adopting a different project approach
In fact, it makes more sense to build a web project in the way that scientists operate. They form a hypothesis about how to solve a problem, they then test that theory and adapt based on the result. In such an approach, failure is merely an opportunity to learn and improve.
That is particularly true with ecommerce sites. By running multi-variance and usability tests on an ongoing basis, we can incrementally improve the site, slowly pushing up the conversion rate.
The damaging consequences of using the wrong approach
Unfortunately, most organizations manage web projects in the same way you would build a factory. That has damaging consequences. It takes a long time to get to market, because of the contracted consultation and specification phases. The money also runs out just at the point when the site goes live, and you can see how users respond to it.
So where does this leave us? How can we shift from a traditional project methodology to something more exploratory and iterative? The answer lies in how we engage with our clients.
Change the way you work with clients
Clients typically think in terms of traditional projects. That means when they approach you, they will provide you with a specification and expect a fixed price and deadline in return.
One way to respond to this is to challenge that approach and suggest a more agile and iterative strategy from the outset; an approach charged on a time and material basis, rather than fixed cost. This can be a big ask for many clients. Time and materials can feel like an open chequebook, and the lack of definition around deliverables will make them nervous.
"Consider suggesting an approach where you aim to launch a minimum viable product quickly, and follow up with an ongoing program of work post-launch."
Instead, consider suggesting an approach where you aim to launch a minimum viable product quickly, and follow up with an ongoing program of work post-launch. In other words, don’t put ‘go live’ at the end of the project, but in the middle instead.
Also, make sure you bake in testing with users at every step of developing the minimum viable product, while including multi-variance testing for the post-launch phase.
Taking this kind of approach allows you to provide the client with a fixed price for the minimum viable product and even a deadline for its delivery. However, you are also able to introduce them to the idea of iteration and ongoing improvement through testing.
Selling an iterative approach
The key to the success of this technique is two-fold. First, keep the cost of the minimum viable product as low as possible with only essential functionality. Second, give the client a sense of what they will get in the post-launch phase, without it being too restrictive.
For example, your initial build might not include discount options or recovering abandoned carts, despite the fact these were in the client’s specification. Instead, you could suggest including these in the post-launch phase, but that can be decided based on user feedback post-launch.
Price the post-launch phase differently to the initial build. Instead of being a fixed price for fixed deliverables, it should be a monthly retainer. The client would pay a fee for a certain number of hours per month.
These hours could be used to develop new functionality such as the discount codes or cart recovery, but you could also use them for multi-variance testing and site evolution. These decisions can be made based on what we learn about user behavior post-launch.
The post-launch monthly retainer should be on a rolling one-month contract to get the client into the mindset of continually evolving their site. However, either party can cancel that ongoing arrangement with one month's notice.
You might also like: The Seven Deadly Sins of User Experience Design.
The Benefits of an Ongoing Agreement
When you present this carefully, clients find it an attractive arrangement because it reduces their risk. The initial outlay will be lower than expected because you are only launching a minimum viable product, and the ongoing retainer does not tie them to you as a supplier. If they don’t like you or are unhappy with your work, they can look elsewhere. Also, they avoid the danger of building functionality that users don’t care about, while at the same time improving conversion through testing and iteration.
From your perspective, the benefit is that you move the client onto an ongoing retainer that allows you to improve the site over time continually. As long as you can continue to increase conversion, the client will keep paying so reducing your need to find new clients continually.
Read more
- Typography in UI Design
- The Top 4 Reasons Users Abandon Their Carts and What to Do About it
- 10 Ways to Improve User Engagement for Your App This Valentine's Day
- Is Your Mental Model a Confusing Mess to Users?
- Tips for Creating Multilingual Digital Products
- Content Strategy: The Principles we Followed to Build the New Shopify App CLI
- How to Use Eye Tracking in Usability Tests
- Building a VR Shopping Experience for the Web: Tips and Takeaways
How will you adopt an iterative approach to your projects? Let us know in the comments below!
