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;
Warning:
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.
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.
Developer goes off and builds something, half the features don’t work.
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.
A bunch of hoopla with little impact.
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. Seriously
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.)
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 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)
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.
Check for quality, grammar, age, findability, analytics, &c.
The best feeling is when you find something almost nobody else remembers.
Language is culture.
(The answer is yes.)
Or the active or passive voice
(The active voice, duh.)
(The data suggests? Bleh.)
Use a spacebar or arrow keys to navigate
(Press “P” for presentation notes.)