Web Production Tips, Redux

A while back, I got asked for tips on Web production, a little random but offered what it’s worth. Slightly updated from an earlier post, 2/20/2018. Feel free to share with those in the web game.

Random Website Production Tips courtesy of Arthur Smith

• Sign your work: I’ve found it useful to make sure people put their names (or at least initials) on all concept stage and later docs (specs, treatments, mission statements, wireframes, page designs, whatever). I used to only ask for dates, but “signing your work” may actually improve quality and it is also a godsend later when you are trying to track something down from an archive.
• Number wireframes: Decimal numbering navigation trees on wireframes/screen comps has been helpful. (That is, assigning a number to each path (Home page =1, a sub-page like “about us” = 1.1 etc.) although as complicated hierarchies become less prevalent on sites, may not be as important.
• Responsive from the get go: Checking responsive view compatibility really early and being psychologically prepared to clip the wings of a really nice design solution and content strategy if it’s not feasible.
• Workflow realism: Be prepared for clients’ (or partners) non-use of proposed workflow tools for content, delivery and review etc. To paraphrase Dorothy Parker, you can lead a client to BaseCamp, Google Drive, DropBox, SharePoint or whatever, but you can’t make them click. Most people are reluctant to add another tool to their work ecosystem, and a vendor seldom has the leverage to persuade them to do so. I ask how clients already work with copy, visual assets, and do review for existing projects, and then work out an approach based on that that’s bearable for the web team. It is often email attachments, the bane of any web producer, but then I put them in the tool I need and name them using the production convention. I work on small sites, and I realize something this ad hoc may not scale.
• Milestones: Rally around a fixed external event to shape client schedules and expectations (even if it’s a sort of made up event). It’s best if there is a plausible date to tie production milestones to, but even if not, designate one based on something on the calendar. For instance, end of a semester for an academic client, annual meeting for a non-profit, etc. Some public version of a deliverable should be tied to this., “e.g., we will focus group the alpha at the next regional meeting.” What’s key is that be such a date be front of mind for client and feasible for you. End of contract dates don’t necessarily work this way. For one thing, they can be amended, but dates of public meetings cannot. If you have to keep looking up a date to see when something major is due, it’s a bad sign.
• Presentation tools for sketches: Consider Keynote, (or if you must, PowerPoint ) for concept and design stage work. If your designers are comfortable with it and particularly if you are working from a family of templates, have designers create plausible Keynote “page shells” that then can be updated by producers and writers to iterate content strategy. This is sort of a hack, and it’s not what Keynote is for, per se, but it is much more convenient (and less costly) that working on content revisions in a designer/Photoshop workflow. For one thing, text in Keynote is much easier to move around and chunk, and the graphics tools are sufficient at least to wireframe, or even do simple page design. Photoshop (or other image tools, are not text friendly). Don’t leave the designer and developer out of this phase, though. It’s possible to create something in Keynote that is insane to execute. Periodic check ins on feasibility and implications are good, as is working from a shell that both the designer and developer have seen and ok’d, or better participated in.
• Start early on copy and other content: Also, if you are careful, you can get a jump on cleaning up the copy, and sort out images, rights etc., in this Keynote stage, not just resolve the content strategy problems. Interestingly enough, now that I work mostly in WordPress, I still find that this Keynote workflow helps. WordPress sort of tempts you to think you can do iterative content development if you have chosen the right theme etc. This hasn’t worked for me: it’s a publishing content management approach (presentation and content wrangling) it’s not a content creation tool, at least for anything editorially intensive. Google docs or DropBox Paper/Hackpad can be your friend here, but most of all choose a tool that your team is likely to use.
• Map editorial workflows: figure out in advance how copy (and other assets) are getting from the client or the writer to the site, and how revisions, proofreading/copyediting and publishing will be done. Note who’s job it is, and do a ‘pre-flight’ to make sure this approach will work. Particularly important for big sites or conversion jobs.
• Restrain your theme addiction: If you are in a WordPress world, or other theme-based platform, don’t move to the theme choice stage until content strategy is established. (This is really hard for me, and others I’m betting. There are so many themes, and it’s fun to think in a preliminary way about your project and then go “theme shopping”.) The danger is you start thinking about the project in terms of what the theme will do, rather than what the project goals are. (It’s a version of having all those typefaces available in a design program: sort of irresistible to try them out early on.) It’s also a waste of time learning a theme and its quirks, only to find out you won’t use it later. (Although this only happens once in my experience!) If you are building a theme from scratch, or redoing most or all of the CSS, then this would not necessarily apply. Still good to have a clear idea of what success looks like for your content first.
• Stay in touch: Do a weekly report email to clients, include milestones from your project spreadsheet or PM tool, and color code tasks: on time (green), behind, (red) ahead (blue), not started (black), so it can be glanced at (but not edited).
• Keep track: Document as you go. (Like flossing easy to say, hard to do).
• If timelines change, be realistic: If some stage takes a lot more time than it was scheduled and budgeted for, the natural tendency is to believe the “Just So story” that you will “catch up” later. If the first stage took twice as long, it’s likely that the other stages will take twice as long. Make an alternate Plan-B version of the schedule that uses this delay as a factor for all remaining stages. For example, if it took the client 10 weeks instead of 5 to provide copy and signoff on concept spec, multiply all remaining stages (page designs, alpha, testing, whatever) by 2 and see where that gets you. Figure out how you could manage such a schedule, and find a professional and respectful way to address this with your client. This isn’t very comfortable, but even if you are just thinking through it yourself is useful. As difficult as it may be to bring up a delay like this with a client, it is easier than trying miraculously do work in half the time. Even if you end up eating the time, your client and team may well respect you for being realistic about it.

• Love your content: Finally, it’s my experience that if you like the content and do right by it, many workflow problems either don’t occur or are easier to solve. Even neutral professional content that isn’t your particular specialty can be rewarding to work on, and if everybody believes it is valuable to get it out to the people who need it, that gives you some basis for working together and solving problems when they come up.  On the other hand, content that hasn’t been worked out pushes back, and chokes workflows.