(This is part 2 of a 3 part series.)
We discussed the importance of questions and planning in the last post, and now we’ll dig into how to get the most out of your client/developer relationship.
Your developer wants to make you happy
I can guarantee that any worthwhile developer wants to build you something amazing and to please your audience, and you. No good developer sets out to make a ho-hum website. We’re pretty ego driven creatures and want to produce great work that we’re proud to show our friends and family, colleagues, and future clients! We’re excited by the web and what it can do, and we want to make you and the user happy. (Who’s a good boy then?!)
Web development, along with any craft, has limitations. The main design limitation we face with websites is that the internet is still, and always has been, comprised of rectangular containers. Think of websites as a series of documents. When you take all the bells and whistles away, including any styling, you are left with a page full of text.
Which means even titles and paragraphs are blocks too (just think of how you insert a text box into a Word document). Every block of text will take up all the width they’re given. Which is why it’s very similar to a printed document, BUT because it’s responsive, it’s closer now to an animated document; Squeeze the browser and things shift, make it full screen and they go as large as possible (to a certain limit); try it on your favourite website; it’s cool!
Please, put those print designs away
We’re designing a website which is functionally different to designing a fancy printed document. We have to keep in mind that decorative elements must be flexible and follow web, NOT print conventions. Meaning, anything fancy must stay out of the way of images and the text content as the screen gets smaller, because these embellishments will move depending on the width of the viewport. It’s better to embellish the website and then make sure they get out of the way when the screen size changes, and to do this we write simple rules which hide that embellished content at a certain screen size and smaller.
Now that we understand a website is a flexible, changing, adaptive document, we can start filling it with content. When should we first do this? The Design phase (see the previous post, Part 1)! If not, we’re giving up the chance to discover content issues as early as possible.
Before a Developer starts building your website two designs need to be agreed upon:
- The desktop design
- The mobile design
Consider these two stages the blueprints of your property build. In the design mockups this content needs to be flexible too. Videos are a good example. Normally videos are static and don’t naturally scale down when they have less space (in fact they are stubborn and always stay the same size!) but, we can take steps to make them responsive for mobile. This is done with javascript which takes the original size of the video and dynamically resizes it based on comparing it’s original ratio to the available width; geeky stuff! But it looks really nice and the video then plays the responsive game with us consistently.
Of course you’ll want images and text on your website, and they will resize nicely but we have to serve up the right image at the right time – we don’t want a desktop-sized image loading on a small mobile device for example, it’s more than is required and will be slow! We can replace images with smaller versions using more javascript trickery which I won’t bore you with here. But suffice to say the code would read, “If the screen is large, provide a large image; if it is small, provide the small one instead.”
Now you can see I would REALLY appreciate knowing what you’re planning on putting on your website so I can plan ahead (and please you and the user in the process; win-win!)
Your website is nothing without content, which is why I harp on about content so much right from the beginning. A website is a blank page, so your website would be pretty boring if there was no content.
Let’s go back to the something we talked about in Part 1 – Personas. Text and images speak directly to your user, so be direct and clear and talk directly to her. Definitely don’t address a large group; just one person. Yes, I know you want as many customers as possible, but a 25-year old single male plumber is going to use your website differently than a 55-year old married female lawyer. This is no time to mumble or be indecisive, you need to immediately answer the user’s problem in a way she understands, so you need to be clear who that person is and how she communicates in order for her to trust and accept your message.
What this also helps us with is the design and it also exposes other problems to solve which is why the design step is so important, followed closely by what technology is actually available.
We can now find out:
- Can we accomplish what has been designed and is that the right content and design for the user?
- Would your user be delighted by that 30 minute video you want to produce or would one sentence of well-written text be better?
Phew, now we can build the site!
Everything from this point on is about hierarchy. We prioritise development, content and design according to user priorities (their hierarchy of needs) so it all makes sense to your user. This includes everything from page titles to whether a video goes at the top or bottom of a page – the user’s priority drives these decisions. Giver her what she wants.
Let’s pretend your user is a 25 year-old female aspiring lawyer, we’ll call her Ella.
Ella will expect a certain tone, casual and cool without trying too hard or the message – the “help” we’re providing won’t work. Being consistent and real gives credibility to the website and puts Ella at ease, she’s then more likely to accept your help instead of going somewhere else.
To give you a clear idea of how this works. Think of a site you go to but only trust for some but not all of its content ( Yahoo.com is a perfect example.) That site is taking on too much and trying to please everyone. It’s a news portal linking to other sites, a place for you to check your email and shop and do 100 other things. You probably don’t go to that site regularly and when you do it’s only briefly because there’s too much information with no hierarchy. Which means you read one thing and then leave before getting overwhelmed, if you expected much from a “one-stop-shop” site, you would be disappointed.
You don’t have to be a developer to understand how the technology behind it works. But having an idea of what it can and can’t do means you’re not (overly) disappointed when you hear me, your developer, say “sorry, that can’t be done”. With enough time (and money!) anything can be done, but as humans living in the real world we cannot create more time.
While technology can provide a ton of functionality, it doesn’t do it in a way the average person understands (see “the web is series of boxes analogy” from before). Please keep in mind the Developer adage: “code is like concrete” and it’s usually at this point that developers disappoint their clients. We’re really not trying to disappoint, remember our goal is to make you happy, but some things just can’t be done, or at least, can’t be done within the budget and time frame, so there are several potential reactions to this, some might be familiar:
- Passive resistance (Silence. This can lead to the feeling that your developer is slowly and quietly backing away from the project)
- Direct resistance (“Why do you want to do this?”)
- Open frustration (“This is dumb, why are we doing this?”)
I have created a website based on the agreed upon design, goals and specifications. I’ve built it so that some changes can happen and content is able to be changed. Yes, changing the paint colour is straight forward, but swapping the bathroom and the living room is a whole different story – get out the sledgehammers and start knocking down walls!
It’s make or heartbreak time for me, your developer
It’s right about now that you can break your developers heart and cause many unseen rants and sleepless nights when you change the plan, or don’t stick to it. If you’ve seen your website in the early stages and realise ‘What I’d really like to see is XYZ’, what that says to me is: “I didn’t really know what I wanted in the first place and what I want is something quite different to what we agreed upon in the design rounds.” You can see why your developer starts to resist your ideas and changes. Behind the scenes your developer is likely very angry and feeling betrayed because of all the work that was put into that foundation wasn’t what you really wanted. Now you can see why working on the foundation is very important!
But it’s only a little tweak!
Moving content containers around or only showing selected content in a different way than was originally agreed up, can derail a project and cause me to retreat into a dark cave. It doesn’t seem like a big deal from your client perspective, but it can be for me. It’s a great idea to listen to my expertise – this is what you’re paying me for after all. Compromise can be reached when everyone agrees on changes in expectations on the project.
My hope, and expectation, is that nothing will change even though deep down I know this is unrealistic. The best way for me to handle this is to understand why the change must be made and then discuss with you why it may’ve been missed early on. This helps everyone understand how much must be done to make it right. It also allows discussion about how valuable the changes would be to the users. Yip there I go again thinking about the User. We also have to keep in mind what’s most important – deadline, budget or quality.
It’s human nature to want all three, but even simple physics says you can’t beat time because it’s limited. That means to get more quality you need to increase budget and time. You also can’t assume that the changes can be completed within the same timeframe. So its best to talk to your developer and trust their time estimates. Always remember your developer wants to please you! That’s his/her primary goal. They’re NOT trying to be difficult. It might be a great idea to have another ‘planning’ meeting so you can both agree on timelines, and for your developer to share with you how the build will go from here on out, as well as explain to you the ease or complexity of your changes.
So the bottom line is to NEVER assume it’s ‘just a little tweak’, because what you think maybe a small change may in fact mean pulling down walls to the house or rewiring the building. Trust is everything here and great things can happen when the team dynamic is strong.
Stay tuned for Part 3 of this three part series, “So when’s it going to be ready?”.
