Sick of the sight of it. Every time we load it up we’re assaulted by its glaring imperfections — each glitch seems increasingly grotesque — we struggle to quiet our melancholy. There are many real and imagined reasons we may want or need a new website. Ugly, slow, difficult to work with (the website) or worse still, it’s so expensive to change the smallest of things that any call to our battle-weary colleagues in IT (or the ebullient caffeinated agency), feels like a hostage negotiation scenario where despite our pleas for proof the captive is alive, none are offered.
Alternatively, we may be told quite out the blue, from on high, that a new website is needed and we’ve been chosen to bend the dreams of the CEO in the direction of reality — a great honour (inexplicably, the deadline will always be before the end of next quarter).
It happens to be January as this is written. We’re sober.
What better time to deal with the practical inconvenience of this seemingly benign endeavour. The precise terror of the undertaking depends on three variables, these are: 1) the size of our organisation, 2) the number of people we must please, and 3) the degree to which their expectations are reasonable given our resources, time, and experience. With thoughts offered to help avoid catastrophe, please read on.
We all know that a successful project first requires a thoughtfully organised and well researched brief. Let’s pause on this point for a moment. Consider if we were to receive the exact opposite of that; a hasty, unstructured collection of demands. How would we feel? It’s a rhetorical question. Amnesty for the guilty is offered here. Of course, we’re all busy but we do ourselves no favour if we hurry when we ought retreat for thought.
This author has read hundreds of briefs and received as many requests for proposal. The best show an appreciation for the separate disciplines. They understand that the task is not merely to ask for, ‘a new website’. Just as a car designer is unlikely to veto the engineer’s specification of a car’s power transfer, so too we must respect the componentry and consider that each part requires its own investigation. If we don’t, our design vocabulary stutters, our thinking stalls and may become tangled — our objectives begin to compete like wronged, tearful siblings and our fear of failure grows. That’s the very definition of project chaos. A good brief is quite simply a vital first foothold.
A brief is a clear description of what we want. It’s useful to remember that there’s always a simple honest ambition nestled underneath. For example, wanting our new house to impress our friends may be at the heart of our brief to an architect yet we dare not admit that. The skilled architect knows this and guides us through a process designed to understand us better. He or she knows our emotional needs matter just as much as shelter — style, form, function, materials, light, heat, hardware, environment and, of course, value for money. Our desires, buried below the surface are excavated, cleaned and presented for examination in the form of (actually) several briefs. Several sets of requirement, collectively forming a complete description of what we want to have built. So it is true for our next website.
That process of discovery is often pitched by consulting firms and web agencies as a billable project that can last several months with thirsty attendant fees. However, if we are equipped with a good brief, there is simply no need to fund another's odyssey. If we know well enough how to construct a brief, we develop a comforting self-assured confidence. Allowing us to fetch easy-to-compare quotes quickly. Importantly, a good brief allows us to canvass opinion from management more effectively because a good brief punctures that very particular type of passive obfuscation senior managers often demonstrate — until at least, the shit hits the fan. Encouraging a sense of ownership from the people we need to please early in the process offers several advantages, not least that it mitigates the volleys of emotionally charged criticism we may endure later.
Brief Deconstruction
It could be argued any website brief is in fact a combination of five sub-set briefs. With honesty, we should attempt to articulate our ambition for each sub-set of requirements with as much enthusiasm as we can muster. The more diligent we are, the more open-mindedly we seek to appreciate (and respect) the complexity of each category of our macro and micro need — the more nuance we discover. This is good. It allows for inspiration and opportunity to soak into our creative mix, brightening our ability to articulate what we want, whilst strengthening our belief in what is possible.
What will it look like?
What will we say?
What will it do?
How will it work?
What will we achieve?
If we scrape away the many layers of bull-jargon, aren’t these the five questions we’re really asking ourselves? And so it seems that deconstructing our brief in this way is useful. However, asking questions without possessing some opinion of the answer is a sure tell we need to think harder and do more personal reflection. Chunking up a large task in a carefully considered way allows us to do just that. Think of this as a guided meditation in mindful web design brief writing.
Sub-set brief No.1: What Will it Look Like? The Look and Feel Brief
We’re building a website, not staking a lawless claim on frontier Prairie land. We use websites everyday. We know what we like. We know what to expect. So, from the get go we already have a pretty good idea of what we want our new site to look and feel like, don’t we? It should be effortless to assemble a list of at least ten relevant websites we admire. A mood-board of reference sites, if you will. To make this mood-board work harder for us, it’s useful to give it structure, organising our reference sites anatomically. For example, we might say that we love how certain websites handle menus, how they treat copy and image, how they present complex data or how they ask for it. How so ever we select our reference sites, its true that our assessment is intrinsically based on two design disciplines: graphic and interface.
And what of our honest ambition? Do we want to turn heads? Are we pitching up? Or are we in the business of modest understatement? Are we Ryanair or NetJets, Polestar or Ling’s? Whatever it is, honesty is always the best policy.
Sub-set brief No.2: What Will We Say? The Content Brief
Our website is often our most important communications channel. There is simply nothing more important than the words we use and the imagery we chose to express our personality and purpose. In the end, a web site is really nothing more than words and pictures illuminated by pixels on a series of scrolling screens. We’re told ‘content is king’, yet the topic is treated as taboo as republicanism is in the UK. And so, the task of creating or fetching content loiters uneasily on our to-do lists. Imagine for a moment, the crumpled expression a literary agent might fix on their face if we presented them with a glossily designed book jacket cover, accompanied with the earnest declaration that: ‘… the title, chapters, illustrations are all tbd — and yes, just fyi… the image on the cover? That’s placeholder…’
It’s commonly remonstrated that we can’t create content until we know where it’s going. This is a false argument and should be roundly treated as such. The more urgent question ought to be, why would the process of generating powerful, evocative, optimistic messages of brand differentiation ever be put on hold? Why?
Our drive to explore ways to bring our sucess stories to life should be irrepressible. Certainly not stymied by the absence of the precise pixel height of a web site banner. Justly, it can be reasoned there is nothing stopping us from briefing for the content we need before any other project task has begun. In fact there is huge advantage in doing so. Not just from a practical perspective of avoiding the crippling distress of discovering our content is not ready in time, consigning ourselves to launching with an apologetic shrug — but also that our message (written and visual) should inspire all that is done in the name of our brand, shouldn’t it? After all, the website is the gallery, the content is the exhibition, not the other way around.
So, with full-hearted affection, its almost inevitable that a prescription of tough love will be necessary. We don’t need wireframes, nor word count limits, nor elaborate publishing work-flows to write an effective web content brief and issue it to our colleagues. We should be principled on this point. Brush aside excuses. Our project’s success truly depends on it. If nothing else, get this right. Words can be edited and images cropped later. That part is the least of our worries.
If we do find ourselves designing with placeholder words and images, the scope of the project may have already crept in the direction of brand. Are we running a brand project along side a customer experience technology project? If so, be alive to this and review again the mandate, project plan and governance accordingly.
Sub-set brief No.3: What Will it Do? The Functionality Brief
Many in our industry rightly talk of the importance of experience design. However, the word ‘experience’ in any context is nebulous. Some may unkindly suggest, ‘fluffy’. After all, who, if asked, doesn’t want a better experience? In our efforts to develop a successful brief we’re wise to replace hazy phrasing with forensic plain-speaking English. Building on the principal thrust of this article which is to simplify tasks by structuring them thematically. Let’s start by considering the three primary reasons any of us visit anyone’s website:
We want to learn more about products or services.
We want to buy or apply for something.
We want to self-serve, that means getting access to a digital service, or locating some customer care without suffering human interaction.
These three themes (learn, buy / apply and self-serve) are universally applicable, however their relative priority will be unique to each of us. And so, as part of any well written brief, we must think about how we describe the desired outcome of each. Here, the following further interrogations may help us:
Today, how much of our website is dedicated to 1) learn, 2) buy / apply or 3) self-serve? Do we have the right balance? If not, how should it be different? Why so?
Today, whether our customers seek to learn, buy / apply or self-serve, what are they thinking and how are they feeling when they click around our site? How do we know?
In the future, how do we want our customers to feel, and what do we want them to do when they visit our new web site?
Reflecting in this way is both rigorous and creatively expansive — affording us the opportunity to think broadly and deeply about the problems we need to solve, whilst avoiding the distracting bias of any preconceived ideas. It’s the very opposite of demanding an interactive office locator map, for example. (I miss Flash).
Sub-set brief No.4: How Will it Work? The Solution Architecture Design Brief
Confusingly, the acronym TCOB stands for taking care of business, yet drop the ‘b’and the meaning changes significantly. TCO means total cost of ownership, which charts highly in the top 10 hits of management speak. Our friends in the tech-pit are proudly obsessed with TCOB which, in a dramatic plot-twist, demands a fastidious regard for TCO. After all, TCO doesn’t just mean, 'please make cheaper', heavens no! TCO means that the way we’ve designed something to work and the way it’s been built produces the best possible cost-to-value benefit not just in the short term but that it will usefully survive for as long as is reasonably possible. A long, healthy, productive life. The very definition of victory for the proud SA.
Our Solution Architecture brief naturally boils down three ways: 1) TCO, 2) performance and 3) use cases. Starting with TCO is no bad thing. Merit badges for credibility on offer if we can amply supply the following in our briefing document:
Interoperability: it’s very helpful if we can provide a full list of every other piece of software our new website must connect to. For example the CRM or ERP, the Active Directory or automatic translation services, such as those provided by Microsoft Azure. The more complete this list and the more detail we can offer with respect to the installation of each, the better.
Extensibility: if we want to add features later (which we will) won’t we rather not be held hostage by the choices made in the first instance? Yes. So, offering the Solutions Architect some clues of what those future features might be may well influence their recommendations. Indeed, this can and should correlate to the grand vision our CEO set out in their initial mandate (lols).
Maintainability: the Solution Architect knows that the less ‘customisation’ we demand of the software products we choose, the better behaved they are. It’s fair to say its often wise to favour buy over build, in so far as possible. Reducing custom code and assembling software products that graciously interoperate, is part of the TCO puzzle we must solve.
Usability: Our colleagues inside and out of IT want to be able to use the back-end system in a straightforward manner to the end that they require: publishing content, extracting data or diagnosing fault. That’s fair, isn’t it? A hygiene factor? You’d think so, but often over-looked causing such headaches for our future selves that we want to fly-tip the whole thing in the Thames (or equivalent tidal estuary).
Part two is performance. We want the new site to perform as well as possible, of course we do. Needless to say, Solutions Architects tend to view performance through especially technical spectacles:
Core Web Vitals: Our brief should cite Google’s Core Web Vitals as a way to ensure that we’re building to the latest and best industry standards: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) First Input Delay (FID) — necessary jargon that we ought to mind but there’s no need to get excessively bogged down in.
Technical SEO: Scoring well on Google’s Core Web Vitals will support our efforts for good search engine optimisation. On top of this, we’ll expect the new site to be scoped in such a way that it supports best practice protocols in terms of link structures, hierarchies and meta data management. Important side note on SEO, don’t get too hot and bothered by it. SEO deserves its own brief, separate from the web redesign project. It belongs to the category of work associated with marketing, specifically customer acquisition but remember SEO is neither a silver bullet nor the priority it may have once been. Google may quite possibly be benign but as the biggest advertising business in the history of humanity, it’s categorically not benevolent. The Wall Street Journal won’t promote our business unless we pay them. And so it goes, Google favours those who advertise and (whisper it) cares little for those who don’t.
Security: We don’t want to have to explain to the CEO that we’ve been hacked and are being held to ransom, literally. Perhaps there’s better phrasing available. Your Solutions Architect can advise. Use as placeholder in your brief for the time being.
Migration of legacy links and data: in an ideal world, the majority of all the migration work will be automated. This requires first an understanding of how much of the old will survive in the new world. Developing the clearest and most detailed understanding of this at pre-project stage is part of the necessary diligence required of a good brief.
Thirdly, use cases. The definition of a use case is:
A specific situation in which a product or service could potentially be used.
Expect to be asked about the use cases of our next website and be ready with fluent answers. Think on the objectives of Learn, Buy / Apply and Self Serve. Think about the ways we imagine users will use the new website. It’s perfectly okay not to describe every detail, but it’s risky to omit the primary use cases from the brief because they anchor it to the very purpose of the ‘product’. The esoteric details and the edge cases will of course be exposed in the rigour of the project.
Sub-set brief No.5: What Will We Achieve? The Business Impact Brief
When we’ve completed the hard work of designing and building our new website, what hopes do we have for its future? What will the new website achieve and crucially, can we resist the urge to request a KPI dashboard, flashing and beeping like the cockpit of an X-wing Starfighter in a dog-fight? (A light-hearted jest. Dashboards, abundant with lagging indicators are invaluable in helping us convincingly post-rationalise under-performance, staving away meddling management enquiry - bulletproof protection when you need it most).
Pragmatically, the success of our project will be measured in two ways:
Efficiency: In an ideal world the running costs of the new site will be less than the existing one. So what is the cost of running today’s site? Omit no line item in our calculations. How many staff work on the site? What is their salary? How much of their time do they spend doing so? Work out the FTE cost associated with that. What about the software licence fees? Hosting fees? Agency fees? Bug fixing fees? Change requests? IT costs? Content creation costs? Add it all up and annualise it. This single cost figure is your cost of operating - your benchmark for efficiency. This is the cost you want to hold or reduce or have a sound case for increasing (excluding the amortisation of the project Capex, obviously).
Effectiveness: Customers are spending more with us since we launched the new site. Does that sound too simplistic? Nothing else really matters. Every other KPI is child to this parent. If we are in a position to separate our customers as ‘digital’ and ‘non-digital’ then our task of benchmarking performance is easier still:
How many digital customers do we have?
How much do they spend, on average per year?
How many did we acquire in the last 12 months prior to the launch of the new website?
A commercially astute brief will contain objective performance benchmarks for efficiency and effectiveness. Without them, it's easy to see how we can get ourselves in a knot when asked to justify the investment we need to do a good job of the project.
Riches for the curious
Writing a good brief requires a curious mind. A willingness to educate ourselves where needed and enough imagination to visualise the end before we’ve begun. In other words, it's an act of science and creativity. Indeed, it is its own project that needs our fullest attention before the true project has even begun. Because, as Barack Obama wisely observed, 'hope is not a strategy', so too, it's true that under-estimating the complexity does no one any favours, in fact it is the most common act of self-sabotage. If we don’t understand, or truly accept how tricky something can be, how can we promise safe passage? As any professional project manager will tell you, cutting corners tends to put us in the red - starving us of the opportunity to fully realise the upside of what we’re trying to achieve. It can be strongly argued, this is especially true when sitting down to write our brief. For anyone in that position now, I hope this article offers some useful guidance. And for anyone with unresolved trauma from a website project they were required to suffer, perhaps some comfort was found here also. Good luck and best wishes in either (use) case.
Talk is cheap.
It’s relatively easy to write essays about theory. The practicality of making it happen is what matters and the devil really is waiting for us in every detail.
In writing this, I’ve tried to imagine what I would have wanted to read before embarkation. Knowing that I wouldn’t want a colour-by-numbers booklet. I’d rather have a set of useful nudges to jump-start my thinking and inspire me to act smart. I do hope what’s written here offers you something of that.
Kommentare