In November 2007, when I was part of what was then the SE web team, we were asked if we could take on a project.
The objective was to completely re-design and rewrite the SE website. Some of you may remember what it looked like back then. Including an incredible floating woman. Stock photography. It’s why we banned it.
Oh. And it had to be ready by 1 April 2008. SE would have a new remit by then. Would that be OK?
Of course, we said. No problem. It’s only a 10,000 page website that we need to start from scratch. And we have almost 3 whole months to do it in. There are 6 of us. We can do that.
After that meeting I recall a rather hysterical après-meeting where the words “not” and “possible” were frequently heard in ominous proximity.
But we did it. We actually did it.
Sure, we all worked all the hours God sent. Or whoever else made time available. We weren’t fussy.
In March of 2008 I worked every single day for the entire month. 10-12 hours a day most days. I let myself off a bit at the weekends, putting in a mere 5 or 6 hours on Saturdays and Sundays.
(This is also the period when I shifted from being a writer/content editor to, by default, technical support … because by then I could write code and we had no-one else to do it .. but that may be another story.)
But mostly how we achieved what I still think was a remarkable feat (the most recent redesign of scottish-enterprise.com took 6 months and involved many, many more people) was this:
- We wrote the content first
Yep. We realised that there was no time to get a web design agency in to do this project. The procurement alone would have taken longer than we had.
We were going to have to do it ourselves. So we started doing what we knew. We wrote.
We hired some copywriters. We “buddied” them with team members so they knew who to talk to, where to go for more information.
We wrote that site from the ground up. And we did it all in Word documents, completely offline. We separated the task of content creation – writing – from publishing and layout. And we hired Rob Catterson and Tara Pattenden to do that job.
Pivotally, we divorced divorced the content from the context of the site design.
There was a reason for that. There was no design. It was happening at the same time. We were being agile, and we had no idea that we were. It was our only hope.
Lisa McGregor and I ran IA workshops to come up with a structure for the site. We covered acres of glass in post-its. Then we attempted to make sense of it all.
Martin Kerr and I wrote code, built templates, designed interfaces. I think we bickered a bit too. I first met his son Rohan then too. On a Saturday afternoon in an otherwise empty Atlantic Quay.
Rob and Tara constantly questioned the content they were given. Both talented people themselves, they rejected content for publication when it didn’t meet the minimal criteria we had specified. Or their own high standards.
That was a genius move, looking back. We had set ourselves up like a proper publisher. Writers could moan all they wanted. But unless they met the standards our publishers (and de-facto sub-editors) demanded, their words went nowhere.
Most importantly, we forced everyone involved – the writers, the publishers, the stakeholders – to focus on the content. They had nothing else to consider, because I was – and I freely admit this – making it up as I went along.
Not only that, I was learning the skills I needed to do it as and when I needed them.
How do you create a SQL query?
Google it.
That’s what I did. Or I found an existing extension in Obtree and copied it then adapted it to do do what I wanted it to to do now. I tried, and failed. Then I tried something else. Then I tried something else. Then I tried something else … you get the picture.
SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
INNER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName;
Eventually, it worked.
I still have no real idea what the difference is between INNERJOIN, LEFTJOIN, RIGHTJOIN in SQL Query. (That’s not entirely true. But mostly it is.)
But what the hey. We found what worked. By trial and error. By making it up as we we went along.
I guess this appealed to my inner punk
And that’s where we need to go … try stuff. Don’t be afraid of failure. Instead, learn from it, Move on.
If you’re not making the same mistakes over and over, you’re improving.
Let’s go that way.
Which brings me to the point
Eventually. But eventually is better than never.
As this UIE podcast – published 7 years later – demonstrates.
In traditional website design and development it’s common to start with the design and add your content later in the process. You may even use “lorem ipsum” as a placeholder to know where the content eventually needs to live. This causes the content creator to craft words to fit the design instead of building a design to fit the content. Without the right content your users will likely have a lackluster experience no matter how good-looking the design.
Steph Hay is an advocate for a content-first approach. She believes it’s important to start with a simple document with all of the content that will be used to communicate with the user. By starting with a document, in plain language, as opposed to a wireframe or comp, all the stakeholders can have an informed discussion. No one needs to be educated on what they are looking at.
Starting with the content helps focus the message you’re delivering to your users. When you build the design out from there, you can more easily determine where the appropriate places are for each type of communication. The site map and hierarchy are born out of the real content that will exist in the final product. You end up with a more cohesive and clear experience.
Hey, who knew?
I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.
Ah memories guys. If you can do that…… all this stuff now should be a doddle!
Yes. Content is critical during the project (and not after). Most of our usability test rounds that have been derailed, have been because the lack of content in a design rendered the tests useless.
3 other points stick with me from that project.
1. Co-Location
We got a project room :-). Room 3.5 in Atlantic Quay was where most of us sat. If you couldn’t get in the room then you sat just outside it. It worked. this is less likely with todays structure and we do need to find ways of remotely getting that same productive environment.
2. Structure, methodology and discipline.
Web design used to be a craft industry but recently it is becoming much more of a science.
Content development is in the same place. It does often suffer from being an art rather than a science. I believe it has to be both but never just one of these.
We ran the project using a DSDM Agile methodology that I brought back from UIE Conference in 2007. Paraphrasing it into our current Scrum Agile approach we:
-Ran parallel sprint paths.
-Reprioritised constantly
Tasks
Our discipline made us only develop content that filled a customers task.
We started with a 10,000 page website.
We relaunched a 750 page website that everyone loved.
I will let you form your own opinion of the content in the other 9,250 pages.
What I can say for sure is that, in 2008 the website was easier for customers to use and much easier for us to measure and manage.
Pattenden. You were close. 🙂
At least she got a menchy 🙁