How to make an

internets

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;

Warning:

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

Requirements

Gather your required deliverables

Design

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

Implement

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

Verification

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

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.

Wishlist

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 souḻs job description without being given any resources.

☝︎ Don’t do this

Don’t do this. Seriously

☟Do this

Ideation

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.)

Research

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…

any persons who are or could be affected by the project,
whether or not they know or care, and
whether or not we know or care.

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

So you know how pages and pieces of content are related to each other

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

Colophon

Museo Sans Condensed, Museo Sans Rounded, & Museo Slab
Impress.js
impress-console.js