Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

How to make an


This is not about how to code a new website from start to finish, it’s more important than that. This is about how to build a process that produces viable web projects that last, are worthwhile, and (hopefully) produce something good. And with that&ellips;


Yer brain on Bernard

  • This presentation is super-opinionated.
  • I work hard to make sure the things I say are backed by research or experience.
  • I sometimes have a way of making super complicated things seems ridiculously easy.

A typical (non-tech) web project


Gather your required deliverables


Make static designs in Photoshop or InDesign, the same way people designed posters.


Hand everything off to the black box known as the programmer to make the magic happen.


Test everything and make sure it’s all working and launch.


Nobody is happy but the project is way late and over budget, so you just launch and hope nobody notices how much of it is broken.


A bunch of people come up with a list of things they think are important, but it always missing something because nobody is able to make a comprehensive list off the top of their head.

“It’s Ugly”

The designer goes off and does something, but key stakeholders are not consulted, so when they come back it gets shot down by the executive director.

Half-baked site

Developer goes off and builds something, half the features don’t work.

Scope creep

Somewhere between steps 1 and 3 a few dozen more features were added to the list of deliverables (we call that scope creep), because nobody was around to systematically figure out what people actually needed versus what they say they need. Time for testing whether something makes sense flew right out the window. Everybody is in over-worked, super-stressed mode.

Do it, already

A bunch of hoopla with little impact.

Slow death

Someone was supposed to maintain the site, but nobody had time. It was probably tacked onto some poor overworked souḻs job description without being given any resources.

☝︎ Don’t do this

Don’t do this. Seriously

☟Do this


Your idea can be anything from a new blog to a brilliant new game. Find smart people you trust and talk to them about it. Smart people will help you refine good ideas, smart friends will tell you when an idea is bad. (Also, be gracious with your time when others ask you to return the favor.)


Sitting around and coming up with ideas can only get you so far. If you’re serious about an idea, go out into the world and observe. Look at what others in your industry are doing. Put on your ethnographer hat, look at what problems people have. (Story of swiffer.)

It’s about the User Reader Constituent

If you talk to a lot of tech people, we love talking about the user experience. Hell, I still put UX advocate on my business cards and resume. but really, users is a terrible term. reader doesn't work either, because we may not be writing to be read, we may be making podcasts, photos, video, or sculpture or convention booths. it's all the same thing. we're dealing with constituents.

Constituents are…

Constituents aren’t just the people who come to our site or use our products, they’re the folks writing the content, the customer service reps, the directors, and board members. Research must include all these folks. In fact, think of constituent services folks as on-the-ground ethnographers, they deal with our loudest constituents *daily*. Going back to swiffer story, we have to look past what people say they want to figure out what they need. And when it comes to internal stakeholders, we have to convince them, too. (which is often the harder part)

Content Strategy & Information Architecture

To understand where we want to go and what is viable, we have to look at what already exists. It’s like putting together an art show, you can’t figure out what to put on the walls without figuring out what you have and whether you need to commission new pieces.

Catalog Everything

  • Everything on the website
  • Print materials
  • Social media accounts
  • Every single domain the org owns
  • Everything on the website
  • Print materials
  • Social media accounts
  • Every single domain the org owns

Check for quality, grammar, age, findability, analytics, &c.

The best feeling is when you find something almost nobody else remembers.

Language is culture.

  • When you write for everyone, you write for no one. Know what you want to say, and who your audience is.
  • Easier for personal projects
  • Necessary when on team projects. Come up with a style guide so the quality and grammar is consistent (such as whether you should use the Oxford comma).

(The answer is yes.)

Or the active or passive voice

(The active voice, duh.)

(The data suggests? Bleh.)

  • Each bit builds on the previous, but it also helps reshape the previous. Nothing is set.
  • Wen you start treating something as set in stone, is the when time starts wearing it away, slow death.
  • what fb does

Plan for the future
  • A blog different from newspaper.
  • Different editorial standards, different voice, different timeline for publishing

  • I prefer to sketch my content models, because they’re ephemeral.
  • Ephemeral
  • What you think is necessary may change as your ideas evolve
  • Don't think about "blog post", think "headline", "tweet text", "short description", "bullet points"
  • Don’t just say you’re going to create new content.
  • Create an editorial calendar
  • not just for creating new content,
  • also revisit old content (to retire)
  • and plan and update the calendar
  • Living style guides
  • Never design with dummy content, give real content more creative freedom
  • can always throw idea out the window
  • college prof joke say throw out first draft
  • Not a joke.
  • 90% never sees light of day

Failure is inevitable

  • The key is to make the impact of failure as soft as possible.

Prototype and test often

  • Sketch with paper and pencil
  • Force yourself to do multipe versions
  • 10% good, 89% crap, 1% genius

Build it, test some more

  • Get something that works
  • don't worry about colors or graphcs
  • paper to code
  • Extra work in the beginning, an hour now saves days later.

Good enough, punch it

  • Websites are not renoirs
  • There is always more work
  • Treat launch day as 1. deadline, 2 good enough to go

Iterate, Iterate, Iterate

  • Celebrate when it goes live, bubble tea
  • Get back to work content strategy
  • prototype first catches problems when it is cheap
  • look for places to improve, make time
  • This should be obvious, but it's hard to do
  • People are bias in favor of the status quo
  • Change is inevitable, if doesn't work as is, change it to make it worthwhile, or retire it
  • Not about the newest toy
  • Play with new things, yes
  • Don't demand people use it unless there is real value


Use a spacebar or arrow keys to navigate

(Press “P” for presentation notes.)