So you are responsible for redesigning the website, but you don't know code? Learn the latest in website best practices and trends, and how to work with designers and tech gurus to make your website attractive, useful, and easy-to-navigate. Chris Lawson Chris Lawson has been building union websites since 1997 - no, you can't see the first one. Chris is the president of the Canadian Association of Labour Media, and a communications officer with PSAC.

1. Help I have to design a website and I don't code
CALM media conference Toronto, Nov 8 2014
Chris Lawson, PSAC lawsonc@psac-afpc.com twitter.com/cmkl
This workshop is going to be mostly about choosing and working with a developer designer or agency.
I will talk a bit about when to self publish but for the most part, it will be about getting someone else to do it for you without losing your mind, your money or years of your
life.

2. Self-publishing vs someone else publishing
• 90% of people running their own websites should not
• Self-publishing tools lessen that pain
• But for most unions these tools won’t suit
• Then what?
DIY vs Developer
90% of the people who run their own websites should not.
Which are you?
Personally, I myself am not sure which I am.
And there are a lot more supports and tools out there that are making the category boundaries fuzzy. Wordpress.com. Tumblr. Instagram.
But regardless of how much of the technical work of providing and hosting a platform, developing and maintaining the application, you will always have to deal with the
content, the users and the correspondents. That might be enough.
So this is why even if you think you’re an alpha geek, you might not want to play that role.
How much of this work do you want to do/can you do?
We don't often have to totally reengineer our sites so a lot of people are just looking for a developer to do the heavy lifting.
But how do you propose to update and maintain your new site? And what are you meant to be doing with it anyway? If you need help with these questions the Dude-

3. Look! Kittens Feel better?
You probably have to hire some form of design, development, site planning help.

4. Do your homework
• Write down your assumptions
about who the site is for
• Test them
• Get some goals
• Learn about your site
Test your assumptions about what the site is being used for.
Often it’s not what’s on the site, but what’s not on the site where you can make improvements.
So don't spend a lot of time reading the entrails of Google Analytics. Ask your receptionist what kinds of calls he or she most frequently fields. Read and categories all
the feedback from your Contact us form for a month. Can any of those questions be answered or issues dealt with by a web application?
Dig a little deeper into people’s sense of problem. “I can’t find anything” will be a common complaint but you need to know more to make solving that problem into a
goal. It could be that people are looking for stuff that’s not there. It could be that your search engine is crap. It could be that your information architecture is
incomprehensible to anyone outside your head office.
There are people who can help you with this stage too, but not as many and their skills/knowledge may not translate as well.
All developers will expect you to know the following
Who are your users
What are their needs
How are they using your site?
What are your requirements?
Throwing up text or are we doing forms as well
What about mobile?

5. How to describe a
requirement
• As an [what kind of user] I want
to [task] so that [objective]
• Don’t be prescriptive
• Phrase them as problems
• Don’t be vague
We often get too prescriptive here. And unless we know the application they’re developing for us intimately, it’s possible the developers know a better way to get to the
apparent goal.
It would be like insisting on going by stagecoach when the train station is across the street.
So phrase your requirements as problems.
“As a content editor, I want to be able to show my visitors an attractive, easy to follow list of items about any given topic on my site starting from the most recent that lets
me highlight or promote what I consider important.
“As a website visitor I want to be able to send a private email to the union without having to know who should be my recipient”.
Don’t be vague. “Social media integration” for example. A sexy buzzword that, when turned into requirements, can be trivial or weeks of work. Phrasing requirements as
problems can help you avoid ‘vague’.
“As an end user, I want to be able to easily share content on the union website on commonly used social media networks in a visually appealing way.”
Too specific would be “Uses AddThis.com to add social media sharing functionality on a per-page basis.”

6. How to pick a
developer
• Is it a DWK or an FSA?
• Are they any good at what you
need done?
Do they do what you need? Is it a DWK, a development company, an end-to-end agency or a person with a raft of subcontractors?
Size of project
Sorts of applications they’ve done
Have they done mobile-first design?
Sorts of clients they’ve had.
How big a company are they?
Can you afford them? Can they afford you?
Do you need bilingual? Can they deliver that?

7. Getting bids and
assessing bids
• RFP vs ‘Conversation'
• What to supply them
• Do you tell them your budget?
• What to ask for
• Sites you like, contemporaries/
competitors sites
• What not to ask for
RFP vs ‘Conversation’
An RFP - request for proposals - is supposedly a neutral competition format for allowing multiple bidders to have the same information and the same opportunities to bid
on a piece of work, ongoing support, or project. You can put this RFP ‘out there’ on your website, on Kijiji, Charity Village, The Globe and Mail or wherever or you can
send it to some companies or individuals you think are possibly a good ‘fit’.
They standardize the format and the content of information you as a client receive from developers (aka respondents) so that you can more easily make comparisons
between responses.
There’s a process laid out where you interview bidders, answer their questions, and share the answers among all respondents.
Then respondents submit their bids.
Does it sound like a lot of work? It is. Can it yield better results than ‘winging it’? Under ideal circumstances yes. Is it fair? Not always. In fact not usually. There’s often an
incumbent. Often a company has an inside track. Maybe you called a developer friend/acquaintance to see what your sort of project would generally cost. RFP
processes favour bigger companies with the infrastructure to prepare bids.
The alternative is a less formal process where you investigate developers who do your sorts of sites to determine if you’ve got a good ‘fit’.
What to supply them:

8. And we want a pony
• Fixed bids vs estimates
• It’s not about them, it’s about
you.
• Yes you
This is an estimate and subject to change.
Developers and designers will prefer to offer estimates mostly because clients are really bad at defining their requirements. (I forgot to mention - it has to be bilingual. Is
that a lot extra?)

9. Why things go pear
shaped Is it inevitable?
It seems like it is. Late. Overbudget. Features missing. I can’t guarantee you that these next few slides will innoculate all your future efforts against this, but here are some
things to watch for.

10. Keep your eyes
on the prize Scope Creep. It’s a thing
Scope creep: aka Keep your eyes on the prize
Keep the original scope document, specification handy. Remember what you agreed to. There’s always going to be that time, money, quality triangle. where if you pull
one corner to make it bigger, the other shrinks.
You can do your bit by not expanding the project scope. And not thinking big to begin with. Three things. Think about three things you want your site to do, like “Look
way prettier, work on a mobile phone and get members in touch with their representatives.”
Recall that if you didn’t ask for X then X is extra.
That whole fixed bid vs flat rate thing? This is why developers prefer estimates and hourly/daily rate projects. Because most people are really bad at getting all their
thinking done at once. They see some feature presented in a proof of concept, or on some other website somewhere and it occurs to them that there’s something else
we should have or do on our site. It’s a natural and normal response to environmental stimuli and it must be crushed ruthlessly.
If it makes you feel better, take these ideas for improvements, critiques and problems, write them down. And file them somewhere. Do not under any circumstances
commit them to a ‘change order’.
If you’ve really done your homework, and your ‘three things’ are solid, this shouldn’t be a problem.

11. Cat herding This could be you
Cat herding
Go from broad consultation to narrow
There’s nothing like bringing in a bunch of new people to the process well after a bunch of decisions have already been made to ensure that a production schedule gets a
new lease on life. One measurable with a calendar.
Start your consultation broadly. As many people as you want. And do let them know what the outcome of their deliberations was.
But if there’s a smaller steering committee, or a reference group that comes from that broader consultation process, ensure they are the only ones who are in on the
project from here on in, and that they are all on the same page. Or bad things will happen.
Respect the phases
We carve these projects up into phases so people can focus on what’s being done now so that we don’t have to re-do things later.
When we’re looking at a wireframe, developers don’t want to hear ‘I don’t like that headline’ because (a) we’re not editing content now, and (b) it means you’re not
thinking about the site’s structure and functionality which is what’s being considered now and (c) it’s likely you’ll come up with some issue around structure and
application design when it’s time for content and (d) we’ll all have forgotten about that headline which we will notice on (e) launch day.

12. Shiny Thing Crush the desire to fix things
Shiny thing
Developers love to solve problems. The geekier and weirder the better. They can detect them from a great distance and track them through snow and high winds.
You must keep them on a leash. This is especially important if you are working with DWK. Development firms have project managers and client service reps to keep the
developers focused. But with a DWK, you’re on your own for this.
Questions to ask: how does this affect our plan to [three thing statement]?
How many people is this actually going to affect?

13. The HIPPO Syndrome Managing up is good
The HIPPO syndrome
The Highest Paid Person’s Opinion Syndrome. This isn’t necessarily about working with your developers, but it will affect how much you have to pay your developers if
you don’t succeed at ‘managing up’. This quintessentially bureaucratic concept is one I’ve come to terms with over the years because it’s really important to do if there’s
some higher power that decides whether the website launches or gets spiked. Like an executive committee of some sort.
Keep it high level. Keep the check-ins frequent and maintain continuity. “Last time we approved a plan for a beautiful, user friendly website that reflected the union’s
image as a positive, community union. Today we’re going to show you the plan for restructuring the website our developers call the ‘wireframe’. Next we’ll be showing
you a mock up of how the website will actually look, in case you’re worried about all the boxes with ‘x’s in them.
This is where having your ‘three things’ statement - your elevator speech if you prefer - will come in handy.
Nor can you presume that just because Marie Claire has been to all the meetings that she was paying attention and has committed your brilliant plan to memory.

14. Business case
• Time to develop
• Time to maintain
• Visitors affected
• Time/money saved
It's a bad word in union land. But I'm going to use it anyway.
We often Imagine the website as our own field of dreams. Build it and they will come. And why not? So much of union work is prescribed by laws, procedures
constitutions and real restrictions imposed by the organization itself.
The web is still sort of the Wild West.
But mostly in real life the ghost players never come.
A business case doesn't have to be a big thick binder. It can be a sentence. If we spend a day of staff time researching who should receive email inquiries, and fixing our
contact for to make sure they get them it will save our staff 20 minutes a day in fielding phone calls.

15. How to provide
feedback
• “The website is broken” not
helpful
• Pictures and links helpful
• Even subject lines in email
• Meaningful subjects for your emails
• URLs.
• Screen Captures.
• Steps required to produce the problem
• Impact of the problem.
You would not believe how many emails I get with the subject 'Website'. That can't be good for anyone. Adding the word 'problem' doesn't help a lot, by the way.
Try: "Calendar not displaying events in order" or "Front page rendering image of space unicorn"
The developers may have a ticket application or project management application they like to use. I would encourage you to at least try it before resorting to email. They
don't all suck rocks.

16. Five steps to
finished
• Content audit/inventory
• Requirements
• Wireframes
• Design Direction
• Alpha/beta
• Launch
See? There’s already some scope creep.
Developers are going to have their own approaches to planning and executing your project. But there’s a pretty good chance they will have stages that loosely
correspond to these.
Content audit/inventory is in here despite the fact that it’s usually not in consideration for web development projects. If you have sense you’ll commit similar resources
to solving your site’s content problems too because often they’re much more noticeable than the fact that the heuristics for your online action form suck.
Also because developers always flag content concerns when you ask them to commit to a launch date.
The Requirements can be dreamed up on your own or in conversation with your chosen developer. Some developers have people on board who are really good at
teasing the requirements list out of people who aren’t technical but have to say what they want their website to do. Beware, though, they may not.
If you can’t ‘describe’ maybe you can show it. Then be prepared to say what it is that’s important (the colour scheme, the simplicity, the fact that it’s multilingual, etc.
Wireframes
Aka boxes and arrows. A skeleton of the website: what goes where and what it’s labelled. Usually goes two or three clicks deep into a website, but is dependent on
budget. Portrayed in sized, plain text with boxes with Xs instead of actual pictures and in black and white.

17. Definitions
• Designer
• Developer
• Themer
• Programmer
• Content strategist
• Information architect
• User experience analyst
• Social media expert

18. Imagine you're here.
Try to breathe.
This deck http://bit.ly/1xl8IKf