We deliver better research when we:

• Have conversations early
• Let the experts do the recruitment
• Check the calendar
• Use a balanced ratio of research and analysis
• Share the journey

Have conversations early

Shaping a research study properly is crucial for good results. Early conversations draw out learning objectives, assumptions, recruitment criteria and potential methods. Involving researchers in these discussions help to develop a solid project foundation and save time later on. Agency researchers benefit by receiving early indications of a client’s research maturity and helps frame future conversations and identify where the best value lies for the client. In-house researchers benefit by providing the inside knowledge of recent and related studies that can offer existing actionable insight, helping to avoid repeated studies at the cost to the organisation.

For both, there is an opportunity to start refining the research goals from day zero so there are no surprises or sudden u-turns at the project kickoff. Likewise, getting an early understanding of the research audience sets us up for a head-start on recruitment.

Let the experts do the recruitment

Recruitment is difficult and time consuming. Although it offers an opportunity to start learning from our audience from day one, the reality is that practitioners seldom have the time. Recruitment is often overlooked and under-resourced as an activity which ultimately impacts the project as a whole.

This underestimation of effort also exists when clients take on recruitment, remarking “I never thought it would be this difficult!” after exhausting their entire panel in the first week with little to no progress. This is not due to a lack of effort on their part, rather the complexity and success ratio that goes with the territory.

Actionable insights hinge on a careful selection of pre-screened and representative sample of incentivised participants. When we cut corners or “just make do” the resulting drop in quality is embarrassingly obvious. Garbage in, garbage out.

Recruitment is a job, unless there is a dedicated role in-house or have the privilege of extra resources, bring in a trusted professional.

Check the calendar

When the research is conducted can occasionally have an undesired and negative impact on results. Each sector has its own peaks and troughs of activity. For instance, the travel sector trading period peaks over Christmas and new year. During this time the stakes are high and there is little room for experimentation. Higher education institutions almost completely shut down over the summer holidays making it difficult to gain access with stakeholders and students.

It’s also worth considering whether other calendar dates might impact participants behaviour. For example, grocery shopping behaviours will differ over bank holidays and other seasonal dates. Likewise, family behaviours will be different over term time and school holidays.

These key dates are often overlooked or not discussed as part of early conversations, whenever planning research activities, it’s always worth asking “why are we specifically conducting the study during this period?” “what might impact our research during this period?”.

Use a balanced ratio of research and analysis

Rich insight comes from spending quality time with the research observations we collect. When the ratio of research collection to analysis is out of balance we compromise on the quality of the outputs. At the very least, we should follow a 1:1 ratio. For every hour we spend talking to participants, spend the same amount of time with our observations.

When it comes to recall our memories are fallible. As time passes we remember events less accurately and become more susceptible to our own biases. This is problematic when we schedule long, concurrent days of research with little time or opportunity to gather thoughts and discuss observations. Shortening the time between research and analysis and introducing activities for sense-making helps us to maintain the integrity of our insights and avoid bias creep.

Share the journey

There’s no doubt that research is a team sport and the value it creates through collaboration. Involving teams across different departments and areas of the business increases awareness and encourages discussions. Together we break down siloed structures within organisations.

Encouraging a broad range of team members across the business to attend research sessions is a step toward creating internal research evangelists. Session attendees invariably find value in what they observe and bring this enthusiasm back into the business. Not only does this encourage cross functional collaboration and the dissemination of customer insight but, more importantly, amplifies the volume of the customer voice and drives the shift toward a true customer centric culture.

This was originally posted on my own website.

5 steps to better research was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

Earlier this year we surveyed over 400 designers working in many different sectors and locations around the world. Our aim was to investigate the current state of design and to determine under what conditions design could be most successful.

Get the report

We’ll be running the survey again early in 2020. If you would like to participate or be notified when the results are out, please drop us your details.

Increasing design impact

Like any investment or operational cost, design needs to be having an impact on the goals of the organisation. We concentrated our data analysis on what organisational and day-to-day practices are most likely to be in place in companies where design was said to have ‘contributed to an increase in sales, competitiveness, and/or brand loyalty’.

The data indicates there are three key factors to increasing design effectiveness. All three ring true here at Clearleft. We’d love to hear your thoughts on if, and how, these factors are nurtured in your organisation. We will be repeating this survey every year to track changes.

1. Empowered by management

The highest performing design teams are those which are empowered by executive management to identify and pursue unplanned or unrequested ideas.

Over half of design teams have the freedom to iterate solutions rather than be expected to get a perfect solution first time. This is incredibly important in maturing your design function, and why autonomy is a core part of life at Clearleft.

However, less than half of the respondents work by developing hypotheses and experiments to test ideas and solutions, showing a gap in structure to enable this freedom.

2. The right environment

Creating a physical environment that supports collaborative design activities is another essential factor present in 9/10 organisations where design is making an impact. Spaces that break down siloes and enable dissemination of ideas and process are not to be underestimated.

This means nurturing an environment where all disciplines can collaborate closely throughout the design and development processes, and giving all employees a good sense of customers and their needs.

While it’s encouraging that design impact can be improved by making simple environmental changes, it’s worth keeping in mind that while a collaborative workplace is important, the empowerment of design teams by executive management to pursue unplanned ideas is vital to design impact.

3. The importance of doing research

Over half of the design teams that have contributed to an increase in sales, competitiveness, and/or brand loyalty do design research regularly or at scale. In contrast, of those organisations where design was not having an impact, 95% are undertaking little to no design research.

Companies with the most effective design functions have integrated research and design teams. They are set up with research and design distributed throughout the organisation. The work of those disciplines is shared with the rest of the employees so that research and design become fundamental to the decision making and strategy of the organisation. It’s easy to see why and how this is beneficial to the business results as a whole, and perhaps why we’re seeing the increasing rise of Research ops.

What’s next?

We hope you enjoyed the insights we gleaned from this survey. By downloading the report you should gain some ideas about what your company can do to improve the effectiveness and impact of its design teams. drop us your details to be a part of the 2020 survey.

If you’d like to discuss the report on the phone or in-person or share insights from your own company email us at info+report2019@clearleft.com

This article was originally published on Clearleft.com

Design Effectiveness Report 2019 was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month Clearleft hosted a lively morning of debate around ‘Accelerating Your Digital Design Maturity’ featuring leading industry voices from Tesco, Babylon Health, Sky, Twitter, Google Ventures and UCL.

In front of an audience of 70 design leads, two panels explored the challenges and approach their organisations have around getting closer to customer needs and delivering better products faster, or to use a couple of industry buzzwords: research ops and design ops. We wanted to share some key insights from the former.

What is research ops?

Research ops are the processes necessary for understanding customer needs and integrating research into an organisation’s decisions. It is the latter part that can be most challenging.

It stands to reason that research ops should ensure that researchers have what they need to do their job. That might include the right software, labs and other tools, training and professional development. It should also include consistent methodologies for different forms of research, along with all the legal and administrative systems and paperwork required.

But that’s a baseline. Where research ops really comes into its own is in establishing research across the organisation. According to Daniel Burka (Director of Product and Design, Resolve to Save Lives), research ops needs to “be both selfish and selfless” meaning it must be objective in its pursuit of insight and understanding, but then open and active in socialising the results.

Design research vs. market research

In many large organisations there is an insights team tasked with market research. This kind of research has been around for many years and has earned a mature place within companies. Conversely design research is relatively new. Some of the techniques may be similar, but the purposes tend to be different, and practitioners in the two camps can have a tendency to look down on one another, with design researchers dismissing market research’s focus groups and the insights team not seeing why they should spend time watching usability testing.

Of course both have their place and the panel stressed the importance of the insight team joining design researchers combine their efforts in understanding the desires of the market and the direct needs and difficulties of customers.

Do we need specialist researchers?

Unanimously, yes, there is definitely a role for specialised researchers. A trained researcher will be able to put together a programme of research and design sessions with users that are as unbiased as possible, non-judgemental and objective. But more than that, Tomasz Maslowski (Head of UX & Design, Tesco) pointed out that an experienced researcher “doesn’t just play the notes but hears the space between the notes.”

So while it’s really helpful that designers, developers, product owners, executives and others are all taken into the field at various points, the skill of the specialist research is to distill what people say into what people mean. The non-trained ear can be prone to confirmation bias and pick out the soundbites and opinions that supports their theory or position, or not take what they are hearing into context or proportion.

Research should collaborate and communicate

You could say that about any discipline, but Dan noted that if you put research among designers then they can hear where designers are unsure about decisions and bring that into their research.

Dan points out that a potential problem with product design is assuming that users care about the product when what they really care about is what a product can do for them. Researchers can help expose this if they are working closely with designers, rather than the design or product team simply giving research a list of questions to get answers to. “They should be the team’s questions, not the researchers’ or the designers’ questions”. Quite often the more useful research questions lead not to answers but more questions.

This is why research is far less effective when done in isolation. It’s time for researchers — and research ops — to “get scrappy” and think about how to get learnings into the wider team, and up to executive levels. Examples include running mandatory “customer closeness” sessions enabling all employees to see first-hand customers using products.

Ultimately the panel concluded that research’s job is to mitigate risk and confirm (or deny) opportunity, and these are aspects that the whole organisation needs to understand and use.

Many thanks to Daniel Burka (Director of Product and Design, Resolve to Save Lives), Tomasz Maslowski (Head of UX & Design, Tesco), James Stevens (Director of Group Product Design, Sky) and Kate Tarling (Digital and Design Leadership, Fly UX) for their generous time.

In part two we’ll cover the second panel and ask what design ops is and whether we should care about it?

Join us next time

We’ll be running another free breakfast panel for design leads in March 2020. If you’re interested in being on the panel or in the audience, please let us know [using this form](https://clearleft-rr.typeform.com/to/IIdIfX) and we’ll get back to you with details nearer the time.

(we won’t contact you about anything else but if you’d like to discuss how we could help you mature your research function do get in touch).

This was originally published on Clearleft.com

The rise of research ops a view from the inside was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

While a product is a tangible thing that can be measured and counted, a service is less concrete and is the outcome of using skills and expertise to satisfy a need. However, the digital space has certainly blurred the lines between products and services, so it’s no longer sufficient to define a product as something you can “drop on your foot” (The Economist, 2010) In fact, it’s actually quite difficult to explain the difference without getting tied up in quite complex linguistic knots!

In the digital space we talk a lot about products; many organisations have Product teams with Product Owners supported by Product Designers working towards their product strategy by progressing through their product backlog. There is a lot of debate about what makes a good product and how to deliver them, but what about the services that underpin them?

Are we doing ourselves an injustice within the digital space because we are obsessing about thinking in terms of products? Is this reducing our remit to tackle and design the entire system it exists within rather than merely how you interact with it?

So how do you determine if you are working on a product or a service, below is a tool to help you do just that…

This model highlights that although you might be positioning yourself as working on a digital product more often than not it’s a vehicle for service provision. After all, people only want a product because it gives them an experience and an outcome.

The model also highlights that in some cases the entire service is embodied in a digital product, think of the likes of Netflix, Uber or Spotify. In these cases, there is a massive opportunity for ‘Product Teams’ to influence the entire service experience, thinking not only of the end-to-end customer journey but also the front-stage and back-stage workings. This would involve exploring not only the customer interactions but also the operating model, the content workflow/approvals, the business model and even down to the governance structures.

So my advice, therefore, is to recognise when your product embodies a service and push your remit to explore the entire design challenge.

Are you designing a product or a service? was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Listen to the audio
• Watch the video
• Download the slides

Jeremy

Our story begins with the Big Bang.

13.8 billion years ago

This sets a chain of events in motion that gives us elementary particles, then more complex particles like atoms, which form stars and planets, including our own, on which life evolves, which brings us to the recent past when this whole process results in the universe generating a way of looking at itself: physicists.

A physicist is the atom’s way of knowing about atoms.

— George Wald

By the end of World War Two, physicists in Europe were in short supply. If they hadn’t already fled during Hitler’s rise to power, they were now being actively wooed away to the United States.

64 years ago

To counteract this brain drain, a coalition of countries forms the European Organization for Nuclear Research, or to use its French acronym, CERN.

They get some land in a suburb of Geneva on the border between Switzerland and France, where they set about smashing particles together and recreating the conditions that existed at the birth of the universe.

Every year, CERN is host to thousands of scientists who come to run their experiments.

Remy

Fast forward to February 2019, a group of 9 of us were invited to CERN as an elite group of hackers to recreate a different experiment.

We are there to recreate a piece of software first published 30 years ago. Given this goal, we need to answer some important questions first:

• How does this software look and feel?
• How does it work?
• How you interact with it?
• How does it behave?

The software is so old that it doesn’t run on any modern machines, so we have a NeXT machine specially shipped from the nearby museum. This is no ordinary machine. It was one of the only two NeXT machines that existed at CERN in the late 80s.

Now we have the machine to run this special software.

By some fluke the good people of the web have captured several different versions of this software and published them on Github.

So we selected the oldest version we could find. We download it from Github to our computers. Now we have to transfer it to the NeXT machine.

Except there’s no USB drive. It didn’t exist. CD ROM? Floppy drive? The NeXT computer had a “floptical drive” — bespoke to NeXT computers — all very well, but in 2019 we don’t have those drives.

To transfer the software from our machine, to the NEXT machine, we needed to use the network.

Jeremy

62 years ago

In 1957, J.C.R. Licklider was the first person to publicly demonstrate the idea of time sharing: linking one computer to another.

56 years ago

Six years later, he expanded on the idea in a memo that described an Intergalactic Computer Network.

By this time, he was working at ARPA: the department of Defense’s Advanced Research Projects Agency. They were very interested in the idea of linking computers together, for very practical reasons.

America’s military communications had a top-down command-and-control structure. That was a single point of failure. One pre-emptive strike and it’s game over.

The solution was to create a decentralised network of computers that used Paul Baran’s brilliant idea of packet switching to move information around the network without any central authority.

This idea led to the creation of the ARPANET. Initially it connected a few universities. The ARPANET grew until it wasn’t just computers at each endpoint; it was entire networks. It was turning into a network of networks …an internetwork, or internet, for short. In order for these networks to play nicely with one another, they needed to agree on using the same set of protocols for packet switching.

Bob Kahn and Vint Cerf crafted the simplest possible set of low-level protocols: the Transmission Control Protocol and the Internet Protocol. TCP/IP.

TCP/IP is deliberately dumb. It doesn’t care about the contents of the packets of data being passed around the internet. People were then free to create more task-specific protocols to sit on top of TCP/IP.

There are protocols specifically for email, for example. Gopher is another example of a bespoke protocol. And there’s the File Transfer Protocol, or FTP.

Remy

Back in our war room in 2019, we finally work out that can use FTP to get the software across. FTP is an arcane protocol, but we can agree that it will work across the two eras.

Although we have to manually install FTP servers onto our machines. FTP doesn’t ship with new machines because it’s generally considered insecure.

Now we finally have the software installed on the NeXT computer and we’re able to run the application.

We double click the shading looking, partly hand drawn icon with a lightning bolt on it, and we wait…

Once the software’s finally running, we’re able to see that it looks a bit like an ancient word processor. We can read, edit and open documents. There’s some basic styles lots of heavy margins. There’s a super weird menu navigation in place.

But there’s something different about this software. Something that makes this more than just a word processor.

These documents, they have links…

Jeremy

Ted Nelson is fond of coining neologisms. You can thank him for words like “intertwingled” and “teledildonics”.

56 years ago

He also coined the word “hypertext” in 1963. It is defined by what it is not.

Hypertext is text which is not constrained to be linear.

Ever played a “choose your own adventure” book? That’s hypertext. You can jump from one point in the book to a different point that has its own unique identifier.

The idea of hypertext predates the word. In 1945, Vannevar Bush published a visionary article in The Atlantic Monthly called As We May Think.

He imagines a mechanical device built into a desk that can summon reams of information stored on microfilm, allowing the user to create “associative trails” as they make connections between different concepts. He calls it the Memex.

Also in 1945, a young American named Douglas Engelbart has been drafted into the navy and is shipping out to the Pacific to fight against Japan. Literally as the ship is leaving the harbour, word comes through that the war is over. He still gets shipped out to the Philippines, but now he’s spending his time lounging in a hut reading magazines. That’s how he comes to read Vannevar Bush’s Memex article, which lodges in his brain.

51 years ago

Douglas Engelbart decides to dedicate his life to building the computer equivalent of the Memex.

On December 9th, 1968, he unveils his oNLine System — NLS — in a public demonstration. Not only does he have a working implementation of hypertext, he also shows collaborative real-time editing, windows, graphics, and oh yeah — for this demo, he invents the mouse.

It truly is The Mother of All Demos.

39 years ago

There were a number of other attempts at creating hypertext systems. In 1980, a young computer scientist named Tim Berners-Lee found himself working at CERN, where scientists were having a heck of time just keeping track of information.

He created a system somewhat like Apple’s Hypercard, but with clickable links. He named it ENQUIRE, after a Victorian book of manners called Enquire Within Upon Everything.

ENQUIRE didn’t work out, but Tim Berners-Lee didn’t give up on the problem of managing information at CERN. He thinks about all the work done before: Vannevar Bush’s Memex; Ted Nelson’s Xanadu project; Douglas Engelbart’s oNLine System.

A lot of hypertext ideas really are similar to a choose-your-own-adventure: jumping around from point to point within a book. But what if, instead of imagining a hypertext book, we could have a hypertext library? Then you could jump from one point in a book to a different point in a different book in a completely different part of the library.

In other words, what if you took the world of hypertext and the world of networks, and you smashed them together?

30 years ago

On the 12th of March, 1989, Tim Berners-Lee circulates the first draft of a document titled Information Management: A Proposal.

The diagrams are incomprehensible. But his supervisor at CERN, Mike Sendall, sees the potential. He reads the proposal and scrawls these words across the top: “vague, but exciting.”

Tim Berners-Lee gets the go-ahead to spend some time on this project. And he gets the budget for a nice shiny NeXT machine. With the support of his colleague Robert Cailliau, Berners-Lee sets about making his theoretical project a reality. They kick around a few ideas for the name.

They thought of calling it The Mesh. They thought of calling it The Information Mine, but Tim rejected that, knowing that whatever they called it, the words would be abbreviated to letters, and The Information Mine would’ve seemed quite egotistical.

So, even though it’s only going to exist on one single computer to begin with, and even though the letters of the abbreviation take longer to say than the words being abbreviated, they call it …the World Wide Web.

As Robert Cailliau told us, they were thinking “Well, we can always change it later.”

Tim Berners-Lee brainstorms a new protocol for hypertext called the HyperText Transfer Protocol — HTTP.

He thinks about a format for hypertext called the Hypertext Markup Language — HTML.

He comes up with an addressing scheme that uses Unique Document Identifiers — UDIs, later renamed to URIs, and later renamed again to URLs.

But he needs to put it all together into running code. And so Tim Berners-Lee sets about writing a piece of software…

Remy

Tim Berners-Lee’s document is a proposal at that stage 30 years ago. It’s just theory. So he needs to build a prototype to actually demonstrate how the World Wide Web would work.

The NeXT computer is the perfect ground for rapid software development because the NeXT operating system ships with a program called NSBuilder.

NSBuilder is software to build software. In fact, the “NS” (meaning NeXTSTEP) can be found in existing software today — you’ll find references to NSText in Safari and Mac developer documentation.

Tim Berners-Lee, using NSBuilder was able to create a working prototype of this software in just 6 weeks

He called it: WorldWideWeb.

We finally have the software working the way it ran 30 years ago.

But our project is to replicate this browser so that you can try it out, and see how web pages look through the lens of 1990.

So we enter some of our blog urls. https://remysharp.com, https://adactio.com

But HTTPS doesn’t work. There was no HTTPS. There’s no HTTP2. HTTP1.0 hadn’t even been invented.

So I make a proxy. Effectively a monster-in-the-middle attack on all web requests, stripping the SSL layer and then returning the HTML over the HTTP 0.9 protocol.

And finally, we see…

We see junk.

We can see the text content of the website, but there’s a lot of HTML junk tags being spat out onto the screen, particularly at the start of the document.

Jeremy

<h1> <h2> <h3> <h4> <h5> <h6> 
<ol> <ul> <li> <p>

These tags are probably very familiar to you. You recognise this language, right?

That’s right. It’s SGML.

SGML is the successor to GML, which supposedly stands for Generalised Markup Language. But that may well be a backronym. The format was created by Goldfarb, Mosher, and Lorie: G, M, L.

SGML is supposed to be short for Standard Generalised Markup Language.

A flavour of SGML was already being used at CERN when Tim Berners-Lee was working on his World Wide Web project. Rather than create a whole new format from scratch, he repurposed what people were already familiar with. This was his HyperText Markup Language, HTML.

One thing he did add was a tag called A for anchor.

Its href attribute is short for “hypertext reference”. Plop a URL in there and you’ve got a link.

The hypertext community thought this was a terrible way to make links.

They believed that two-way linking was vital. With two-way linking, the linked resource connects back to where the link originates. So if the linked resource moved, the link would stay intact.

That’s not the case with the World Wide Web. If the linked resource moves, the link is broken.

Perhaps you’ve experienced broken links?

When Tim Berners-Lee wrote the code for his WorldWideWeb browser, there was a grand total of 26 tags in HTML. I know that we’d refer to them as elements today, but that term wasn’t being used back then.

Now there are well over 100 elements in HTML. The reason why the language has been able to expand so much is down to the way web browsers today treat unknown elements: ignore any opening and closing tags you don’t recognise and only render the text in between them.

Remy

The parsing algorithm was brittle (when compared to modern parsers). There’s no DOM tree being built up. Indeed, the DOM didn’t exist.

Remember that the WorldWideWeb was a browser that effectively smooshed together a word processor and network requests, the styling method was based (mostly) around adding margins as the tags were parsed.

Kimberly Blessing was digging through the original 7344 lines of code for the WorldWideWeb source. She found the code that could explain why we were seeing junk.

<link rel="..."

In this case, when the parser encountered <link rel="…" it would see the <.

<

“Yes, a tag; let’s slurp it up”.

<li

Then it reads li and the parser is thinking, “This looks like a list item, good stuff.”

<lin

Then encounters the n (of link) and, excusing the paring algorithm because it was the first, would then abort the style it was about to apply and promptly spit out the rest of the content on screen, having already swallowed up the first four characters: <lin.

k rel="stylesheet" href="...">

With that, we decided to make the executive design decision that we would strip out any elements that were unknown to the original WorldWideWeb browser — link, script, video and img — which of course there was no image support in the world’s first browser.

This is the first little cheat we applied, so that the page would be more pleasing to you, the visitor of our emulator. Otherwise you’d be presented with a lot of scary looking junk.

So now we have all the reference we need to be able to replicate this browser:

• The machine running the original operating system, which gives us colours, fonts, menus and so on.
• The browser itself, how windows behave, what’s in the menus, what makes the experience unique to that period of time.
• And finally how it looks when we visit URLs.

So off we go.

Jeremy

While Remy sets about recreating the functionality of the WorldWideWeb browser, Angela was recreating the user interface using CSS.

Inputs. Buttons. Icons. Menus. All with the exact borders, highlights and shadows used in the UI of the NeXT operating system, including having the scrollbar on the left side of windows.

Meanwhile the rest of us were putting together an explanatory website to give some backstory to what we were doing. I spent most of my time working on a timeline showing thirty years before and thirty years after the original proposal for the web.

The WorldWideWeb browser inherited fonts from the NeXTSTEP operating system. It mostly used Helvetica and a font called Ohlfs (created by Keith Ohlfs). Helvetica is ubiquitous but Ohlfs was never seen outside of a NeXT machine.

Our teammates Mark and Brian were obsessed with accurately recreating the typography. We couldn’t use modern fonts which are vector based. We need pixeliness.

So Mark and Brian took a screenshot of the NeXT machine’s alphabet. With help from afar from font designer David Jonathan Ross, they traced each square pixel in a vector program and then exported that as a web font. Now we’ve got a web font that deliberately isn’t anti-aliased. It’s a vector format that recreates the look of a bitmap.

Put the pixelly font together with the CSS interface elements and you’ve got something that really looks like the old WorldWideWeb programme.

Remy

This is the final product of our work at CERN that week. A fully working WorldWideWeb emulator giving a reasonable close experience of what it was like to surf the web as if it were 30 years ago.

This is entirely in the browser and was written using:

• React,
• React Draggable for the windows and menus,
• React Hotkeys for keyboard combo shortcuts (we replicated the original OS as much as we could),
• idb-keyval for some local storage,
• Parcel for bundling.

These tools weren’t chosen particular because they were the best tools for the job, but rather because they were the tools I knew that well enough that would help speed up my development process.

We worked hard to replicate the look and feel as much as we could. We even replicated typos found throughout the WorldWideWeb app:

An excercise in global information availability

Why don’t we see how it looks…

Jeremy

There’s kind of irony in this in that it relies heavily on JavaScript. In fact, there’s nothing there other than JavaScript. But of course the WorldWideWeb browser couldn’t deal with JavaScript — JavaScript hadn’t been invented yet. So the one URL that definitely wouldn’t work in this emulator is …the emulator itself.

Remy

(Which Jeremy was blaming me for.)

This is what you see when you visit the WorldWideWeb browser for the first time. We can see we are welcomed by the universe of hypertext. We’ve got these menus over here that you can drag off and open panels (I always thought this was an ordering bug but the operating system actually works like this).

We’ll go ahead and open the Fronteers website. I go to “Document” and then I go to “Open from full document reference” (because the word URL didn’t exist). I’m going to pop the Fronteers URL in here. And there it is. We’ve got the Fronteers website. Looks pretty good. (One of my favourite UI bits is this scrollbar on the left hand side instead of the right.)

We can follow the links. Actually one of my favourite features that was in this original browser that we replicated was this “Navigate” menu. I’ve just opened the first link in the document, but I can click on “Next”, and “Next” a bunch of times and it will cycle through each one of the links on the page that I launched from and let me read all the pages that the Fronteers site links to (which I really like). I can go backwards and forwards, and so on.

One thing you might have already noticed is that there are no URLs here. And in fact, to view source, it was considered a kind of diagnostic option and it was very very tucked away. The reason for this is that URLs — and the source HTML or SGML — was considered ugly and potentially a bad user experience.

But there’s one thing about navigating here that’s different. To open this link, I had to double-click.

Jeremy

The WorldWideBrowser was more of a prototype than anything else. It demonstrated the potential of the World Wide Web project, but it only worked on NeXT machines.

To show how the World Wide Web could work on any computer, the second ever web browser was the Line Mode Browser, coded by Nicola Pellow. It had a very basic text interface — no clicking on links — but it could be installed anywhere.

Lots of other geeks and nerds were working on their own web browsers, but it was Marc Andreesen’s Mosaic browser that really blew the doors open for the web. It had a nice usable interface, and it (unilaterrally) introduced the innovation of images on the web.

Andreesen went on to found Netscape. The World Wide Web took off at an unprecedented rate. Microsoft brought out their Internet Explorer browser and started trying to catch up with Netscape. We had the browser wars. Later we got even more browsers, like Safari and Chrome, while Netscape morphed into Firefox and Internet Explorer morphed into Edge. And the rest is history.

But all of these browsers were missing something that was in the original WorldWideWeb browser.

Remy

The reason I have to double-click on these links is that, when I do a single click, it actually places the cursor. The cursor is blinking there on “Fronteers.” And the reason I can place the cursor is because I can edit the document.

I see Fronteers here is missing a heading. We want to welcome you all:

Welkom

We want to make that a heading. Let’s style that. It’s a heading.

So the browser was meant to edit documents. Let’s put a bit of text here:

Great talks from Remy and Jeremy

(forget about everyone else). Now if I want to create a link, I’ll go ahead and navigate to Jeremy’s site, https://adactio.com. I’m going to do “Link”, then “Mark all”, which is a way of copying the URL to that window. Then I go back to the Fronteers website, select “Jeremy”, and then do “Link to marked.” I can double-click on Jeremy’s name it will open up his website.

I can save this document as well. I’m going to call it fronteers.html.

Let’s do a hard reboot — a browser refresh. I come back to my machine a couple of days later, “Ah, the Fronteers page!”. I’m going to open that again, and it linked to that really handsome guy in the sprite shirt. And yes, the links still work.

In fact, this documentation that you see when the WorldWideWeb browser launches was written, styled, and linked using the WorldWideWeb browser. The WorldWideWeb browser was for a web that you could read and write.

But this didn’t survive. It was a hurdle that was too tricky to propose or implement across the different types servers that existed and for the upcoming browsers that were on the horizon.

And so it wasn’t standardised and doesn’t exist today.

But this is an important lesson from the time: reducing complexity increases the chances of mass adoption.

In the end, simplicity wins.

Jeremy

I think that’s a pattern we see over and over again, not just in the history of the web, but before the web. Simplicity wins.

Ted Nelson famously to this day thinks that the World Wide Web is weak sauce. It didn’t try to solve complex right out of the gate, like handling micro-payments.

As we saw, the hypertext community that one-way linking was ridiculous. But simplicity does win out.

Unfortunately that’s why browsers ended up just being browsers. We got some of the functionality back with wikis, content management systems, and social media to a certain extent. But I think it’s still a bit of a shame that when I want to browse a web page, I’m using one piece of software — the browser — but when I want to make a web page, I’m using another piece of software (or multiple pieces of software) to get something on to the web.

I feel like we lost something.

Remy

We head home after a week of hacking.

We were all invited back in March earlier this year for the Web@30 event that was taking place to celebrate the web but also Sir Tim Berners-Lee.

A few of us, Jeremy, Martin, and myself, went back to CERN for the the first leg of the event. There was even a video showing off our work as part of the main conference. Jeremy and I even chased Tim Berners-Lee back to London at the science museum like obsessive web fanboys. It was a lot of fun!

The night before I got a message from Jean-François Groff, pictured here on the right. JF Groff joined Tim Berners-Lee 30 years ago and created libwww (a precursor to libcurl).

The message read:

Sitting with Tim right now. He loves your browser!

Crushed it.

It’s amazing that we were able to pull this off in a week just with text editors and information that’s freely available. It’s mind boggling how much we can do today and how far it can reach. And it all started on that NeXTSTEP machine 30 years ago.

What I really loved about this project was working with this brilliantly old technology, digging around at the birth of browsers and the web.

I wouldn’t be stood here today, if it weren’t for the web.

I wouldn’t even know Jeremy, if it weren’t for the web.

I wouldn’t have a career, if it weren’t for the web.

I loved seeing how such old technology, the original WorldWideWeb browser was still able to render my blog. Because I put content first, delivered markup from the server. The page rendered because HTML really is backward compatible.

HTML and HTTP are just text. Nothing terribly fancy. Dare I say, beautifully simple, and as we said before, simplicity wins the day.

This same simplicity is what allows us all to have the chance for an equal voice. The web allows us to freely publish our thoughts and experiences. We have to fight to protect that kind of web.

And we’ve got to work at keeping it simple.

Jeremy

When we returned to CERN for the 30th anniversary celebrations, one of the other people there was the journalist Zeynep Tefepkçi.

She was on a panel along with Tim Berners-Lee, Robert Caillau, Jean-François Groff, and Lou Montoulli. At the end of the panel discussion, she was asked:

What would you tell the next generation about how to use this wonderful tool?

She replied:

If you have something wonderful, if you do not defend it, you will lose it.

If you do not defend the magic and the things that make it wonderful, it’s just not going to stay magical by itself.

Defend the simplicity and resilience that’s so central to the web.

I don’t know about you, but I often feel that just trying to make a web page has become far too complicated. But this is complexity that we have chosen with our tools, processes, and assumptions. We’ve buried the magic. The magic of linking web pages together. The magic of a working global hypertext system, where nobody needs to ask for permission to publish.

Tim Berners-Lee prototyped the first web browser, but the subsequent world wide web wasn’t created by any one person. It was created by everyone. That. Is. Magical.

I don’t want the web to become a place where only an elite priesthood get to experience the magic of creation. I’m going to fight to defend the openness of the world wide web. This is for everyone. Not just for everyone to use; it’s for everyone to create.

This was originally posted on my own site.

How We Built The World Wide Web In Five Days was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whether you’re a content strategist, service designer, or work in customer experience, you need to know how content connects across your business.

Understanding the content that finds its way to the customer, or informs how you communicate to customers, is vital to understanding the experience you’re providing across all interactions customers have with your brand.

Here’s an example matrix showing the types of internal and external content. You may not have considered how much internal content you have that informs what a customers sees or hears. The quality of your internal content can impact your customer’s experience just as much as the content they see or hear directly.

Improve your products

Content experts are often left out of the product development process. When product naming conventions or feature names are defined, they often stick, and unfortunately this means something that started out as an internal name or company jargon finds its way onto the website or app and then doesn’t resonate with customers. Involving content experts in this process means you’re always thinking about how the product or feature will be perceived in its final implementation and using the language of the end users.

Provide better customer conversations

Other areas with neglected content are internal tools and call scripts. The systems and call guides that staff use inform the conversations they have with customers. Involving content experts in the development or optimisation of tools and processes can have a hugely positive impact on the service provided. Spotting opportunities to improve scripts or content in the UI of internal tools shouldn’t be left to chance — content designers are just as valuable on your internal-facing content.

Check your feedback loop

One way to make your own content stronger is to make sure the right people see user-generated content. This could be social media comments about service, live chat conversations or customer complaints. If digital content teams never know why people are phoning up because they’re stuck onsite, or customer service teams never get to find out what customers are complaining about on Twitter, then how can they improve? Sharing the qualitative insights that sit behind the more commonly used data such as NPS scores can be much more useful and actionable than the scores themselves.

Insight teams need to be connected to content providers and regularly sharing.

Connecting your content

It’s rare that a central content team would create all the content shown in this example matrix. It’s much more likely that content creators sit in pockets of the business, such as marketing, UX teams, customer experience, brand or customer comms.

One way to better connect these teams is to think about content in terms of customer lifecycle, rather than by channel, and ensure that all the people responsible for each stage are connected, and talking to each other regularly. This way they can ensure their content and messaging is consistent.

There are techniques the teams can use together, for example journey mapping, which will help identify all the content elements and how they hang together, and identify any opportunities for improvement.

Setting up content steering groups or holding regular content sharing sessions for all creators across the business are also both great ways to ensure alignment. But ideally alignment should start at the top, with a joined-up strategy.

Make it strategically-driven

All content should be underpinned by a shared set of values, principles, voice, and terminology. For customers to trust a brand, they need to see or hear consistent and well-crafted content — any dip in quality or break in consistency will erode this trust.

The best way to achieve this it to have an overarching content strategy. Not only is it key to business success, it will also give your teams direction and provide the frameworks they need to make their content creation efficient and effective.

Who should steer the ship?

To achieve connected content across an entire organisation you’ll need someone to map out the architecture, spot opportunities and highlight pain points. You’ll then need to establish guidlines, create and agree workflows, create shared lexicons, and all of the operational elements that allow teams to do their day-to-day work more effectively. This work can be done by senior content strategists, but to fully embed this across the business you’ll need sponsorship and endorsement from the top down.

Even companies with Chief Content Officers aren’t focusing enough on their internal content problems — they tend to focus on the customer-facing content as people in these roles often come from marketing backgrounds. Perhaps this will change as service design thinking gains traction.

In the meantime, content teams will rely on the advocacy of senior digital or customer experience leaders who fully understand the importance of content.

There’s also often a disconnect between traditional content (editorial and marketing) and product teams. For a business to grow its content maturity it will need to recognise that content lives on the inside and the outside of a business. And far from being invisible to customers, it’s often the back-end content that can have a detrimental effect on the experience with a brand.

Why you need a content team and how to build one is out now on Amazon.

Connect your content for better products and services was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

This was originally posted on my own site.

Back in the late 2000s, I used to go to Copenhagen every for an event called Reboot. It was a fun, eclectic mix of talks and discussions, but alas, the last one was over a decade ago.

It was organised by Thomas Madsen-Mygdal. I hadn’t seen Thomas in years, but then, earlier this year, our paths crossed when I was back at CERN for the 30th anniversary of the web. He got a real kick out of the browser recreation project I was part of.

I few months ago, I got an email from Thomas about the new event he’s running in Copenhagen called Techfestival. He was wondering if there was some way of making the WorldWideWeb project part of the event. We ended up settling on having a stand — a modern computer running a modern web browser running a recreation of the first ever web browser from almost three decades ago.

So I showed up at Techfestival and found that the computer had been set up in a Shoreditchian shipping container. I wasn’t exactly sure what I was supposed to do, so I just hung around nearby until someone wandering by would pause and start tentatively approaching the stand.

“Would you like to try the time machine?” I asked. Nobody refused the offer. I explained that they were looking at a recreation of the world’s first web browser, and then showed them how they could enter a URL to see how the oldest web browser would render a modern website.

Lots of people entered facebook.com or google.com, but some people had their own websites, either personal or for their business. They enjoyed seeing how well (or not) their pages held up. They’d take photos of the screen.

People asked lots of questions, which I really enjoyed answering. After a while, I was able to spot the themes that came up frequently. Some people were confusing the origin story of the internet with the origin story of the web, so I was more than happy to go into detail on either or both.

The experience helped me clarify in my own mind what was exciting and interesting about the birth of the web — how much has changed, and how much and stayed the same.

All of this very useful fodder for a conference talk I’m putting together. This will be a joint talk with Remy at the Fronteers conference in Amsterdam in a couple of weeks. We’re calling the talk How We Built the World Wide Web in Five Days:

The World Wide Web turned 30 years old this year. To mark the occasion, a motley group of web nerds gathered at CERN, the birthplace of the web, to build a time machine. The first ever web browser was, confusingly, called WorldWideWeb. What if we could recreate the experience of using it …but within a modern browser! Join (Je)Remy on a journey through time and space and code as they excavate the foundations of Tim Berners-Lee’s gloriously ambitious and hacky hypertext system that went on to conquer the world.

Neither of us is under any illusions about the nature of a joint talk. It’s not half as much work; it’s more like twice the work. We’ve both seen enough uneven joint presentations to know what we want to avoid.

We’ve been honing the material and doing some run-throughs at the Clearleft HQ at 68 Middle Street this week. The talk has a somewhat unusual structure with two converging timelines. I think it’s going to work really well, but I won’t know until we actually deliver the talk in Amsterdam. I’m excited — and a bit nervous — about it.

Whether it’s in a shipping container in Copenhagen or on a stage in Amsterdam, I’m starting to realise just how much I enjoy talking about web history.

This was originally posted on my own site.

Geneva Copenhagen Amsterdam was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been called an ‘Ergonomist’ designing a national transport system, I’ve been called a ‘Service Designer’ designing an end-to-end airport passenger experience and more recently at Clearleft I’ve been called a ‘UX Designer’ designing a relationship management product for a large investment bank. However, the one thing that has stood me in good stead throughout my whole career is taking a system’s approach to all problems — no matter whether they are at a service or product level.

I’m not a fan of the phrase ‘digital service design’

The benefits of taking a system’s approach at a service design level is well understood. The whole premise behind service design is that an experience should be designed across all customer touchpoints — including understanding how the tangible and intangible components influence one another within the whole system. It’s one of the reasons the new term of ‘digital service design’ has never sat well with me as, unless the service is 100% digital, dividing the service design between the digital and non-digital parts defeats the object.

At a product level, your brief is typically more focused on an individual/subset of product(s) or service ’touchpoints’. However, it’s absolutely critical not to lose sight of where this component sits within the broader service strategy — what is your role, what is your relationship with other touchpoints and how might your design decisions influence other areas of the service.

Ultimately, the experience is defined by all touch-points, not just the ones you are focused on.

The risk of not maintaining a systems mindset

Not maintaining this system mindset at all levels is one of the reasons in my experience that it’s all too easy for the original service strategy to get lost at execution or take a life of its own. One of my favourite quotes of all time is this one by Steve Jobs which highlights that the journey from idea to product is rarely a straight one:

“You know, one of the things that really hurt Apple was after I left John Sculley got a very serious disease. It’s the disease of thinking that a really great idea is 90% of the work. And if you just tell all these other people ‘here’s this great idea’ then of course they can go off and make it happen. And the problem with that is that there’s just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows. It never comes out like it starts because you learn a lot more as you get into the subtleties of it. And you also find there are tremendous tradeoffs that you have to make.”

Steve Jobs

Successful innovation relies on both service and product-level design working hand-in-hand. This is importantly a two-way relationship that requires everyone to understand that executed well the whole can actually be greater than the sum of all the parts.

This post was originally published on Clearleft.com

Applying a system mindset at both a service and product level was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.

I don’t know about you, but I need methodology and theory to be really simple, and also visual. ‘Draw me a diagram’ is often my go-to line. I find it very hard to make the abstract tangible and practical without clear diagrams and examples.

For this reason I sometimes struggle to articulate content strategy to clients and colleagues. It’s essentially the substance, tools, people and process that get you to your outcomes — or how to focus your efforts to achieve your goals. And that’s important, because without focus you’re just building ‘stuff’ without purpose.

But when it comes to breaking that down into tangible things that a business can do, I just couldn’t find a diagram that said what I wanted it to. So I’ve created my own.

It made sense for me to think of a strategy in the form of a process – the steps to get from here to success. So the steps I’ve come up with are:

1. Focus

What are you trying to achieve as a business, and what do your users need? Thinking about your user goals in terms of business value can help to align these.

For example, if customers are seeking more information on a particular topic, by providing that info you can keep customers onsite for longer and increase the chances of them buying. You meet their needs and by doing so, sell more.

While the overall goal you are trying to achieve through content is probably sales or loyalty, think about the more granular metrics that contribute towards this about might be more relevant to user needs.

Once you’ve drawn out the areas to focus on, you can define a content mission statement.

2. Foundations

In order to create effective content you need to lay the foundations. This consists of:

• your values (which are aligned to your content mission)
• voice and tone
• the substance and structure of your content, ie. WHAT will you be creating or refining?

Once you know what you need to create, it’s easier to work out how to get there.

3. People

It goes without saying you’ll need someone to create or refine your content. Perhaps multiple teams and disciplines need to be involved? Setting out the roles and responsibilities is particularly important when you don’t have a defined content team. Who needs to provide product information, and who has overall accountability for the content once it’s live? No accountability isn’t just dangerous from a quality point of view. If no one’s reviewing the existing content once it’s live then you’re accumulating content debt.

4. Process

The next thing to focus on is your production and build process. This could be very simple if you’re a team of one or embedded in a product team. But if you’re in a large, fragmented organisation it’ll be more complex. Creating briefing templates or setting SLAs (service level agreements) might even be necessary if you’re managing a vast number of stakeholder requests. The great thing about defining metrics and KPIs is that you now have a criteria to prioritise content against. If it’s not contributing to business goals or metrics then is it really a priority, or do you need to include other objectives options in your brief such as ‘legal requirement’?

If you have a CMS it’s best practice to document the workflow and list out creators, editors etc. Even if this is just to keep track of who has access. You’ll need to make sure there’s a process for removing users when they leave the business or adding new users when they join too.

Under process I’d also include style guides and QA checklists. Part of any content production is ensuring it’s governed in such a way that whoever produces it achieves a high quality and consistent piece of content. When multiple content creators exist you’ll need guidelines to make sure this happens.

4. Measurement

Much like the agile process of test and learn, we must make sure we’re tracking against our targets. Whether this is through analytics and data, or more qualitative feedback such as usability testing, we need to revisit what’s gone live. In the case of a large website with multiple content producers, it’s advisable to review the content at regular intervals and check it’s still accurate and fit for purpose.

5. Maintenance

Once our content’s live our work isn’t done. Iterating content, testing new versions (through AB testing) and optimising for usability isn’t just advised, it’s essential if we want our site to be the best it can be. We all like to think that when we hit publish that it’s the best work we’ve ever done. But the chances are that looking at your site with a critical eye will highlight lots of room for improvement.

Content strategies are only achievable with buy-in from senior stakeholders, which is sometimes tricky. My top tip is to include them in the strategy creation process. Start with stakeholder interviews to understand what they think the company should be trying to achieve through content, and bring them into any workshops you run. In a recent presentation by Gather Content I heard:

“70% of businesses don’t feel their content adequately addresses user needs”

so the appetite for better content is there. But better content doesn’t just happen — it starts with a better strategy.

A new way to talk about content strategy was originally published in Clear Thinking on Medium, where people are continuing the conversation by highlighting and responding to this story.