A new platform build represents a substantial investment for a publisher. Getting to pay-back quickly, and ensuring that this new development fulfills all the bright hopes that the business held for it, ought to be a guiding priority. But the language we use to talk about web development, and the habits of mind it gives rise to, often obscure the importance of ROI, and lead us to believe that the development team’s job is all done and dusted the moment a new site gets launched. A website isn’t a house – and here’s why.
Readers in the UK, parts of Europe and beyond will be familiar with the popular TV programmes Grand Designs (US residents less so – but bear with us). This programme follows architectural homebuilding projects from planning stage through to completion. Along the way, the plucky self-builders encounter setbacks like budget shortages, schedule over-runs and unexpected life events.
Though the programme’s popularity has endured throughout its 15 years of existence, so familiar and repetitive have these hitches become – surprise pregnancies, losses of employment, refusals of planning permission and so on – that a has evolved around them.
Player of the game take a drink when, for instance, participants are forced to spend Christmas in a caravan when work over-runs, or suppliers come up with bespoke fittings that don’t fit.
‘There are all kinds of rules,’ says the show’s host, Kevin McCloud; ‘like every time I use the word “bespoke” it’s a double shot …’. McCloud has admitted in the press that, ‘we actually wrote an entire programme around the drinking … one of the programmes is deliberately designed to get people as drunk as possible.’ Despite the vicissitudes endured by the show’s participants, each episode follows a formulaic arc in which repeated setbacks finally lead to a triumphant ending when the build is finally completed, and the grateful family can take up occupation to the accompaniment of tinkly, upbeat music and swooping crane shots (by which time players of the drinking game are no doubt comatose).
Does anything about this setup feel familiar?
You’ve probably clocked by now that I’m leading up to some kind of house-build/web-build metaphor with this. But it might not be exactly what you expect. Because the purpose of this post is not to institute a new drinking game based around the things that go wrong with platform builds (e.g. take a shot if a business-critical requirement got missed out in the original specification) – fun as that would be.
No, quite the opposite. What I want to point out is how unhelpful it can be to think of creating a new publisher platform as being similar to building a house in the first place.
What happens after the build?
There are metaphors embedded in the words we use every day in digital publishing – site, platform, portal, build – that do a useful job of making understandable and real something that is essentially intangible. However there are times when these metaphors just get in the way.
We talk of ‘building’ a website – and immediately start thinking of the endeavor as something akin to building a house. This brings with it certain presumptions about the team we employ to work on it for us, one of the major ones being that when the house is completed they will get out of our hair and leave us alone. We will then only have to speak to them if something goes wrong that can be laid at their door – if the plaster cracks, or the guttering drops off – in which case we call them back and ask them to put things right (and then go a bit red in the face when they ask for more money).
Applying this logic to a platform build creates an assumption that once the site is delivered, project management will hang up its hard hat and hand over to the support and maintenance team – who then bug-fix reactively until the word comes down in two to three years time that the CEO has got tired of looking at the site and wants a redesign. This is, unfortunately, a very prevalent mindset in publishing, among both digital publishing teams and developers alike. But it is increasingly out of sync with best practice in website strategy, as well as with the way web digital strategies are evolving. Furthermore, it isn’t even a particularly accurate picture of what actually happens in the real world.
Agile but unsexy?
So what is the reality that these house-building metaphors disguise?
To start with, very few web launches are accompanied by tinkly, upbeat music and swooping crane shots – even in the imaginations of the project team. Most launches are deeply anticlimactic. And for this reason. Since all major developments are subject to scope creep – the result of over-stuffed requirements lists at the outset, compounded by new opportunities and affordances discovered during the process of the build – many end up having to be de-scoped in order to hit a deadline. As a result, ‘phase 2’ is already being planned well ahead of the looming launch date, with all the ‘sexy stuff’ the team got so excited about during the build deferred till after launch.
This tendency for software builds to fragment into phases is so universal a phenomenon that project management has incorporated it into new agile techniques such as Scrum, that organizes work in a series of ‘sprints’. It has also given us deeply unsexy terms like Minimum Viable Product (MVP). This is the reality of software development. It pines to be evolutionary and Darwinian, in a world dominated by Gant-sheet-wielding creationists (‘just get it done in seven days, Charles’). Deadlines are deadline: but if we are too locked into a ‘Grand Designs’ mindset that sees launch as a complete endpoint of the process, we risk falling into an unhelpful cycle of over-inflated expectations leading to disappointment, followed by failure to capitalize on our learnings … rinse and repeat.
Secondly, website development is speculative to a degree that buildings – bound by strict regulations, planning laws and the ergonomics of the physical human frame – can never be. In a building, there is generally only one way to get through a door. On a website there are usually multiple ways to reach your destination. Besides which, a website is just not a house. You never really know how people are going to use the site until it is launched – or even who will come to it. So, even with the best user research in the world, the process of web design involves a lot of second-guessing of ‘the user’. And ‘the user’ remains something of a fictional character until the site is open for business, and begins to be interacted with by real human beings.
Post-launch user data is richer – but does it play to an empty room?
As I found in my investigations of UX design for this blog post, observing user behavior on a site provides a more high-value type of information than asking people to report their experience through user surveys and the like. To put it crudely: watching what they do gives you richer information than listening to what they say.
But user research carried out as part of the design and build process, despite technological advances in the field, has limitations in gathering this type of data. Sample sizes are necessarily small, historic date gives no indication of how users will react to new features, and watching user interactions on a pre-launch beta build doesn’t necessarily give the full picture.
Once a website is launched, however, you can observe far larger numbers of users operating in real conditions through your web and access analytics. So in many ways, the information available to UX teams after launch is much richer and more valuable than what can be gathered during a typical design phase – and your ability to make meaningful, evidence-based changes that much greater.
The tweaks and modifications you can make to a site post-launch, once you can see how real people are interacting with the site, therefore ought to have a good chance of making a positive effect on the bottom line. Unfortunately, in most web projects, the UX team is usually not around to help you take advantage of this.
Real (not fictional) users are on your site, broadcasting their intentions and wishes. But like 20% of the golf on TV, this broadcast could be playing to an empty room. Think of the financial upside you could be missing out on by not making the vital connection between analytics and ROI.
Keeping that MVP viable
The conclusion this line of argument is heading towards will sound familiar to many ears: be more iterative, evidence-based and agile in your approach. Any number of web design gurus will tell you that you should realign, not redesign.
However, in our market, there are forces that trigger redesigns other than aesthetics and UX. You might want to migrate to a more technologically sophisticated or innovative platform technology. You might have an eye on discovery (another factor that only really kicks in once a site is live) and switch to a system that will improve that. You might want to make your content more friendly for content mining (TDM), more searchable, more findable.
All of these considerations should also prompt thought about what happens after the build. The technology is fast-evolving, SEO is a movable feast: how will your solution keep pace? What is the roadmap? And most importantly, who is going to stick around after the solution is delivered to help you fine-tune it and make the thing work?
At HighWire we’ve put a lot of thought into these issues and the result has been a change in how we envision the relationship between web development and the business. In particular, we’re focusing more on what happens post-launch, and how we can help organisations capitalize on the ROI in the post-launch period and beyond – as well as avoid wasting money on developments that either don’t get an audience, or don’t chime with users.
We’ll be posting further about these issues on this blog, and you can of course contact us directly if you like to discuss it in more detail how we can help your ‘grand design’ achieve sustainable success … cue tinkly music and swooping crane shots.