Award winning stuff

I've got a bit of a grin on today as I've been told the last project I worked on at ThirtyThree, Claire’s Careers won this month’s Ri5 award for creativity/excellence in recruitment communications.

 You can see the Ri5 award here: http://www.ri5.co.uk/site/news/article/the-ri-fiver-the-summers-musthave-accessory/

Here's what they had to say:
"In the end, however, a clear majority voted for Claire’s website. “There was some impressive competition in this particular batch of entries, but I like the bravery of the Claire’s campaign in that it hands creative control over to the employees,” said freelance writer Phil Woodford. Mark Braun of 360º was impressed too: “Great engagement and it portrays a real sense of diversity as well as individuality.” And Mark Horley, soon to join TMP Worldwide as head of creative, loved it: “I think this a fantastic example of the employer brand being embedded deep into the organisation. Seeing how the spirit of the brand lives from the UK, to Spain, to Germany, to the Chinnigans (watch the movies) is fantastic. It’s a wonderful example of employee engagement and a real draw for prospective joiners.” And finally, freelance art director Ed Collingwood had this to say: “A nice, welcoming, interactive site that's really on-brand. I particularly like the fact that the video interviews provide a transcript of the dialogue. This attention to accessibility is something which I think is often overlooked when including this kind of content on websites.”

And the site in all it's glory here: http://www.clairescareers.co.uk/

Well done to everyone who worked on this one!

Why QA is important and not just an afterthought

QA or "Quality Assurance" is an integral part to any project digital or otherwise. We do it because we want our end product to work, we want our client to be happy, we want our users happy. QA is never optional.

QA is NOT an afterthought - it should be an essential part of every step of the project
Imagine this purely hypothetical scenario. You're a phone developer... you develop a new handset, you spend millions researching and developing the hardware and software, millions more on marketing and bringing it to market. How embarassing would it be if you then found that the phone you spent so much on bringing to market didn't make phonecalls reliably? No doubt people would laugh at you, your company reputation would be damaged. Fortunately this is hypothetical and has never happened.

If QA is considered from the very start of a project then the dedicated QA team can ensure that what is delivered at the end matches the requirements set out at the start. The requirement "must make phonecalls" will be tested by the QA team all the way through from the initial design (does the phone sit in your hand, is it comfortable for a phonecall?) to technical specification (are we including technology that lets you make phonecalls) to delivery (we've built the phone, does it work - yes it does). If QA is an afterthough then you might have spent millions on design, research, specification, building prototypes, etc to only find that money has been wasted because your phone doesn't make phonecalls... if a QA team was involved from the start then at everystage they can ask - has this phase of work done what it's supposed to, is this a quality bit of kit, has this been done right?

QA is NOT only for big projects.
Why would QA not apply to small projects. QA means you only output quality work - if you skip it for smaller projects, even a tiny banner or minor copy change, then you still risk that those tiny bits of work could be crap (lack quality)... QA EVERYTHING.

QA does NOT mean purely technical testing.
Testing that a website works doesn't just mean do the buttons go to the right place. A proper QA will ask - do the designs match those signed off? Is the architecture of the site fit for the user? Does the copy have any typo's? Is the content in the right place? Can the server handle the expected number of users? Does the code meet standards (e.g. accessibility)? Does it match the functional and technical spec? Have we overspent?

QA can be carried out by anyone... but it shouldn't be you QA'ing your own work
It's true that bigger pieces of work benefit from a dedicated QA team - but smaller bits of work (or agencies without a dedicated QA team) might not need this. The main thing is - make sure someone has understood the brief, reviewed the work and signed it off.

QA is systematic
QA should be thought out - another reason QA should be considered from inception is it is time-consuming and costs money. It takes awhile to understand requirements, write systematic test plans, understand test requirements (do I need automatic scripts, what should I test on, etc).

QA is not money down the drain
Making sure you test everything seems obvious. If something lacks quality then it devalues the end user experience of the product. If something is worth doing then do it right; you'll save a fortune if you take the time to always get things right.

The ultimate project management tool?

I've just discovered Smartsheet - a tool from Google that is essentially MS Project online. Very cool! So far it seems to do everything you might need and more, including allowing you export into Excel or Project.

Random project management techniques / tips / tools

Managing change requests
From time to time clients will change their mind i.e. every project you ever do – clients change their minds. I believe it’s important to be flexible to accommodate change; within reason. It is the within reason part which needs considering. You should make it clear that a project has a change request process. A few tweaks here and there can normally be absorbed without major impact to budget. But what if they change their whole strategy at the eleventh hour? You need to have set expectations that if they do this there is a cost attached. If templates are built already and they change the whole structure you should always go back to earlier phases, you’ll need to re-do the UX, re-do design – otherwise the changes they’ve asked for may be introduced without forward-thinking and you could end up delivering something that doesn’t work. Not to mention contractors build to an agreed scope; if the client changes their mind and you ask the developer to rebuild something from scratch they are within their rights to charge you for the same work. You can either absorb this from your profit or pass the cost onto the client.

File structure
Using the same file structure anyone can pick up your project easily. My preferred structure is below:

 

Versioning
As a rule I always version sequentially, not by date – simply because windows/mac will sort the files so that the latest version appears last (it is easy to pick the wrong file when sorted by date).
Versioning can be quite rigid: http://en.wikipedia.org/wiki/Software_versioning
But generally I simply go

• Version 0_1 – first draft
• Version 0_2 – second – and so on
• Version 1_0 – first release to client

A minor update goes up by .1, a moderate update by .5, and a large update by a whole 1.0, e.g. if a document is rewritten from 4.0 then the next will be 5.0. If I change a bit 4.5, and if all I do is change a few typos 4.1. Simples.

Launching a site
I would always say it is never  a good idea to launch a site on a Friday or after 15:00 any day. If you put something live you want to have time to respond to any bugs that may have been missed or rise from the upload process. Particularly on Fridays where a bug could remain over the whole weekend.
Always make sure you give the site a final test when it is launched. 

Ensure you haven’t missed anything basic and yet easily forgotten, have you set up a favicon, analytics, etc, have you checked accessibility – e.g. all alt-tags set up on images, metadata, etc?

Testing a site
The site should pass a minimum testing standard of YUI A-Grade browser support -

Sometimes it makes sense to write a test plan depending on the scale of the project. If you've an efficient mind just using common sense on smaller projects can work too.

Many issues that might come up in testing can be avoided with at the requirements gathering stage e.g. don’t propose using Flash if you want it to work on a mobile, build the site accessibly and it will work across most browsers. 

To keep abreast of the latest trends (e.g. should I test in IE6, what screen resolution should I use, etc) take a look at: http://www.w3schools.com/browsers/

Fonts
Want to use a corporate font that isn’t web-safe? You can using image replacement techniques such as Cufon or Sifr. You don’t need to know much about this, just that it’s doable. This means a font, such as the National Trust font, can be used and generated on the fly on a website for titles and headers – e.g. the menu. Don’t use it for body font, sorry – it has to be websafe fonts in this instance – Cufon is great used sparingly but if you use it to replace body-copy it will make huge server demands.

What not to use
Flash – is never suitable for a menu system. It doesn’t work on mobiles. Some users don’t even have Flash. It’s suitable for games and banner adverts – and in the case of the latter ALWAYS have a non-flash alternative. Instead of Flash look for alternatives e.g. explore using JavaScript, CSS3 and HTML5. 

Bespoke video players – You can charge the client money to build a video player (which is costly to get it working properly) and then an ongoing hosting fee as streaming video puts demand on the server and bandwidth. Alternatively, spend the money elsewhere and host it with embedded Vimeo or YouTube.

Bug Tracking

Bug tracking software, when properly embraced, is one of the most useful tools you’ll use on a project.

It allows you to:

• Create a ticket and assign it to a developer.
• Prioritise the order – showstoppers to nice to haves.
• The developer can do the work and assign back to you with a notification.
• Statuses help you track what needs to be done, e.g. “New bug, needs testing, closed, reopened, with client for review”
• Will keep a single audit trail of the lifecycle of a bug – this helps you keep everything ordered so that bug, the one the client spotted, the one that is really frustrating them, never gets lost in your inbox.

Risk Management
When you start a project, and on an ongoing basis, it is worth identifying risks. You can’t predict them all but risk management is an essential part of project management. If you think about risks at the start you can help prevent or plan for them. Here are some commong ones:

• Going over budget - which is why we plan our projects and agree a scope up front.
• Choice of technology – are you using or trying something never tried before. If so your time estimates may be massively out – plan contingency.
• Too many stakeholders – If you have too many stakeholders internally or externally you can end up in the situation of too many chefs spoiling the brew. Identify who really needs to be involved and make sure only they are involved in sign off.
• Holidays – clients, contractors, yourself – again project planning.
• Forgetting the basics – build a checklist, have I set up hosting, analytics, thought about accessibility, etc – even better build the checklist into your project plan.
• Bugs and amends – always plan for things to go wrong, plan for at least one iteration of every deliverable, use bug tracking, prioritise the work to avoid going out of budget. Also, clear briefs mean more will be right first time. 

 

Do these approaches work for websites only?
No – they will work for all digital projects, everything from a basic HTML email or mobile app to an extensive piece of software development.

Project Management and Waterfall

This article outlines the "Waterfall" approach I have generally used in project management and offers techniques and tips to use to help make life easier and to solve some common problems – the end goal is always efficient, profitable, project management that delivers great products we can be proud of. 

Waterfall approach to Project Management 

 

“In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters of other more "flexible" models.” - http://en.wikipedia.org/wiki/Software_development_process#Waterfall_model.

As a project management approach Waterfall is a very natural process to follow. It’s the process we normally use – even if we don’t realise we are using it because it makes sense – you look at the project and break it up into distinct phases. Each phase is critical to the next; each phase must be reviewed and signed off before starting the next. Saying that, there is always scope for some flexibility – however too much flexibility and you risk the project.

The phases in Waterfall are (see diagram above) detailed below:

Concept

Early on you will want to define the concept; particularly for a campaign. This can inform the site requirements, the architecture, and the design.

Requirements Specification

A project should start with a clear specification of what you aim to achieve. A project scope will define what you are going to do and relate this to your budget. It will identify questions you might have – it maybe that you need to build in contingency to plan for unknowns. If you specify what you are going to do at the start then the clients expectations are set and managed from the offset; if they try to change the scope further down the line (eroding margin) you can refer to this original agreement.

At this stage you should define the objectives of the project from the user and clients point of view. The client may want to achieve X conversions or other goals but are their expectations realistic? Always make sure objectives are realistic and measureable.

The requirements specification phase can include standard copy about your project management approach – this helps tell the client how things will be run. Outline the phased approach above and highlight that each phase should follow the same structure – define your brief, carry out the work, test it internally (if it’s not up to scratch send it back), then allow the client to review – if they aren’t happy they will send it back, when they are happy they MUST sign off before going to the next phase. It is sensible to cap the number of times work can be sent back (iterations) from the outset. Otherwise you risk engaging a never ending cycle of review and amends. If the client understands their amends are limited they will provide all their feedback, and review things properly, first time around.

Don’t forget to set up hosting and Google Analytics and purchase URL’s early on. You will also want to agree the cost arrangement and possibly an ongoing maintenance agreement for post-launch.

At this stage you should define technical standards – e.g. The site will meet AA accessibility standards and be tested to Grade-A browser support.

Always build a project plan at the start of a project, share it with the client in a format they will understand most easily. Make it clear when you expect their involvement and what you expect from them.

Don’t forget to identify your stakeholders – your primary contact may project manage their side, but who is responsible for sign off. Your project plan should allow realistic times for everyone client side to do their bit.
Always provide context to any deliverable you hand over – make sure they understand the rationale behind everything you give them.

What if the client just can’t decide what they want?

Sometimes a client will want more things in their project than their budget will allow. There is a solution – sit down with them and create a requirements list. List out every feature in excel and put resource times and costs against it (but keep in mind sometimes you’ll get an economy of scale by doing some work together). Then get the client to prioritise it using the MoSCoW method:

• M - MUST have this.
• S - SHOULD have this if at all possible.
• C - COULD have this if it does not affect anything else.
• W - WON'T have this time but WOULD like in the future. Alternatively WANT.

Help guide them to work out what is really important and what they don’t really do based on their objectives and user requirements. If everything is a MUST have then they will realise they need more budget – but generally they’ll realise that some things just aren’t that important this time around.

A requirements list is also a good talking shop to workshop simpler solutions e.g. instead of a fully interactive video case study perhaps a written one will do, freeing budget for the ATS system they really need.

System and Architecture Development

Before you start to design the look you should consider the structure of your site from the USERS PERSPECTIVE. Produce a sitemap to tell you what pages you will need and produce wireframes to define the structure of each page.

 It is far more efficient to define reusable templates that are flexible for multiple pages, e.g. Homepage, Content Page, Landing Page, Case Study Page, etc. Try and think of the page layout in columns with modules that plug in – this will make your template more dynamic. One template can have hundreds of variations if you have blocks of content that can be turned on/off and reordered.

Always approach from the user’s perspective (not the clients) – who is using the site? How would they interact with the site? What journey (user journeys) will they take to achieve the objective you want them to achieve?

Sometimes it helps to write a user persona – essentially a bio of your typical user e.g. “I’m Geoff, I’m 35 and work in IT. I’m married with two children and live in Berkshire. I’m generally happy with my job but like to keep up to date with new vacancies just in case something interesting comes along. Normally I allow recruiters to find me rather than actively searching for roles” and “I’m David, I’m 25 and work in IT. I live in Reading in a shared house. I currently have a role in IT but I’m looking for my next big move.”
For an IT company based in Berkshire these two personas, typical of your users (do your research into what’s typical; and use intuition), require different solutions to engage them. Geoff has a family; he’s unlikely to relocate, but he already lives in Berkshire. He’s not actively looking but would consider a good job if it came along. A tailored newsletter would help Geoff – you’d have to get him to sign up, but if the newsletter alerted him to jobs relevant and near him Geoff would be happy and may just apply. David is actively searching; good SEO will help him find the IT company in Berkshire. He’s young and not too far, he may relocate – when he hits the site he needs to know that it’s relevant to him and nearby. This will influence your homepage design. Writing personas helps you think about the user and in turn the user experience; they can also help your client who will often think about what THEY want not what their users want until they see a persona – so get the client to sign off on the personas.

Always consider navigation – a horizontal navigation is great for a campaign site with few pages and fixed content, but a content heavy site nearly always needs a vertical navigation or a jumbo drop down. Accessibility is also important when considering your navigation – remember some users will want to increase their text size. Also, if your site might be translated keep in mind that your navigation may need to accommodate long words (e.g. German or Welsh). Your UX should accommodate this – don’t squeeze things in that will break when designed / built.

You will need to think about accessibility at this point. Don’t produce anything that cannot be built by a developer. If unsure get your site developer involved with defining the information architecture of your site.
Often all the above is produced from experience and intuition. If unsure you can try a few methods such as user testing and card sorts to help inform your UX with solid stats. The bigger the project, or the more important that you get it right, the more important it becomes to build your project on researched foundations over intuition. Concepts can be tested cheaply – investigate http://verifyapp.com/ (I’ve not used this service before – but it sounds interesting!)

Produce a content map that describes what goes on each page (what template, which modules - such as twitter feed, case study driver, driver, social media links, etc and include required content. You might want to say “This page serves to tell the user about the company. It will include copy about the companies history, values and culture. It will contain case study drivers that support the main content). Also produce a copy deck which identifies from the outset – what copy needs to be written. Don’t forget drivers, buttons, error messages, help boxes – they all need to be thought about.

If the requirements are not clear you may also want to define a Technical Specification. This will tell the developer how the site should be put together and include sitemaps, content maps, wireframes and later designs. This document will be the bible the site developer builds the site too. It will be what a contractor quotes against, and the stick you slap them with if they don’t deliver (equally, if you don’t put something in the document then they may charge extra as it was out of their scope).

Remember some golden rules in UX

• The homepage is not guaranteed to be the first page a user sees.
• People will NOT have fun “discovering” content – if things are hidden people won’t find them. Clear navigation – always!
• Avoid dead ends – use related links, drivers, on every page.
• Include social media elements to share content easily.
• The shortest pathway to the content you want is the best pathway.
• Don’t get crazy; there is a good reason why many sites are essentially the same. People scan the top left first – it’s fact; your most important content should be here. Your search should be in the top right, the logo top left – break the mould and you may find you confuse people. Breadcrumbs go at the top, not the bottom.
• Ignore me – do your own research; trends change, new research comes out – be cutting edge!

Design
If a concept has not yet been defined it should be. You may want to use moodboards to set a tone for the site. 

Are there brand guidelines that must be accounted for?

A good web designer can work with wireframes and understands that what they are creating doesn’t need to fit on an A4 page. Websites are dynamic, so too should be the person designing it. They need to consider both why the architect has defined things the way they have and also what the developer will do with it next. They need to consider accessibility – it’s no good to design a box that would be impossible to build properly in HTML, e.g. because it uses texturing that cannot wrap. This really requires understanding of how websites are built. 

Ideally you should provide the client with two design routes to pick from. These should be presented in person; never sent by e-mail “What do you think?” but instead in person or over the phone so you can say “This is why we have approached this the way we have…” Also, present it as “Do you think this meets your users expectations”. If you give them a choice of two they will be inclined to choose one; they may ask to choose a little bit from one and a little bit from another. This is normally a bad idea, if they don’t share common elements it’s because they don’t work together. Ideally try to manage it so they pick a design and have only a few tweaks. The more involved they feel the easier the sign off process will be – saying that, don’t be afraid to defend your corner as the digital expert. 


Designs should be optimised for a minimum of 1024 wide. Nobody uses 800x600 anymore. Keep in mind that browsers have scroll bars, so while the screen is 1024 wide, the web design should be no more than 974 - 984 wide. We should all be using grids in layouts, 960 is a great number as it’s slightly smaller than full width, and it’s divisible by 3, 4, 5, 6, 8, 10, 12, 15, and 16 (imagine the grid possibilities).  

Do not be afraid of scrolling. Remember the fold is not a line, it is a region. Do not be obsessed with everything being above the fold – just design in a way where the most important content is above it, and the user knows they can scroll.

Before going to client the designer should have checked the design for accessibility including insuring the colours validate. As a project manager you’ll want to make sure this has happened or check this yourself.

Make sure web-safe fonts have been used or you have the technical scope to use image replacement like Cufon on non-websafe fonts.

A developer should always review a design before it goes to the client – there is no point in exciting the client with something that cannot be delivered.

[NB: Involving the developer in design almost seems contrary to hardcore waterfall approaches. While phases are distinct they should also be a team effort. The UX leads UX, the designer leads design – but other disciplines should be involved to educate and inform the deliverable. Do not think of each phase gateway as a wall – the design should not be flung over the wall for the developer to pick up!]

Programming
The site developers will include the front end developer (working in HTML and CSS) and the back-end developer (working in e.g. PHP, but they could be .NET, ASP). They will deliver the site to the documentation defined at the start (A WTS if one was written).

The front end developer shouldn’t need to alter interface designs to make them work. This should have been thought of at the design stage by the designer.

The back-end developer should understand fully how the site works from designs, wireframes, sitemap, content map – ideally all explained clearly in a single Technical Solutions document.

System Integration
When the programming is done the finished templates need to be brought together with the back-end system and any third party software.

This is also the time that final content should ideally be ready to be added before testing.

System Test
Before the client sees the site internal testing should be carried out. The site should meet the accessibility standard specified at the requirements stage (normally AA) and be cross-browser compatible (meet A-Grade browser support, which now includes mobile)

Acceptance
At the end of every phase the client should review and sign off on content before moving to the next phase.

The acceptance phase is the clients chance to review that the project has been delivered to:

• The agreed specification
• The architecture they signed off on
• The designs they were shown
• Includes the content they have signed off on
• The technical standard they expect (the expectation you set for them)

Normally I suggest a user acceptance testing period (UAT) where the client reviews the site on a demo environment and checks that it is up to scratch. If not they provide a prioritized list of bugs and changes. Prioritised because during scoping you will have defined the amount of budget proportioned to amends. If you only have 2 days and they’ve asked for 10 days worth of amends you are giving them 8 days of time for free. The project manager may want re-organise the priorities, which should be discussed with the client. They might have prioritised something trivial over a bug fix that is a true show-stopper.  

When you and the client are satisfied the project has been delivered to spec it can go live (a final test) and then you can pat yourselves on the back!

Maintenance
It is a fact that in software development you will have bugs – a good client should be able to understand this. I am not saying a site should launch with show stopping errors; but if you dig deep enough you’ll find niggles. Even if on delivery the website seems perfect, browsers and operating systems will change, tweaks are made to the site and/or something was missed. 

When the client has completed the acceptance phase they have accepted the agreed project is done. There is a balance between good account management where you fix some post-launch bugs for free and good project management where you avoid spending the next year giving them freebies. 

For a large project an ongoing paid for Service Level Agreement (SLA) will allow for regular maintenance, bug fixing and updates. Smaller projects may need less frequent updating and warrant charged bespoke maintenance only. 

New functionality should ALWAYS be dealt with as a mini-project, not a bolt-on to the SLA – this means that the new functionality is properly thought out. If it’s just bolted on and added improperly it can and often does cause problems in the site elsewhere and may cost you more than you bargained for.
Don’t forget to keep track of agreed hosting and stats monitoring agreements.
 

Brand new shiny website for Claire's

Blood, sweat, tears, glitter and sequins! It's been a busy fair few months, but after writing a painstakingly organised 29 page "Website and Technical Solution" document (it was mostly wireframes and designs with explanatory text), producing some very refined and carefully constructed Visio wireframes, many iterations of  interface design, a 50 page copy deck, several meetings and a thorough build and QA cycle the reward is here - a brand new careers website for Claire's - see www.clairescareers.co.uk. (Which they love!)

The old site (see below) was off brand and clunky. While a great piece of work when it was launched it had dated.  The biggest challenge I saw were bring a fashion brand like Claire's to life online while at the same time providing a clean and quick user experience for what is essentially a very content heavy site. The solution, jumbo-drop down.

The new site features at the top level large seasonally updated background imagery to position Claire's Careers not just as a recruitment site but to highlight it's a recruitment site for a fashion brand! As you drill deeper into the content the images become banner headers, randomly selected on page load, so that it is the copy and not the image that dominates. Still, Claire's products and seasonal photography dominate every element of the site from the backgrounds, page heading to the drivers that help guide users to related content on the right hand side of every page.

The jumbo nav lets users drill down to the content most relevant to them in one click rather than a convoluted search through landing pages and various navigation elements.

We wanted to introduce a social element to the site so every page features the latest tweets from the Claire's Career's twitter account. Every page, including job postings, contain share this links to Twitter and Facebook and "Add this" which covers most of the other major social networks.

 

To encourage engagement with the Claire's Careers channels every page also gives the user the ability to quickly join their Twitter, YouTube or Facebook channels. 

The site has been built to be as accessible as possible. While it is not mobile optimised, the way it has been developed means it will work on most smartphones to a degree. Every element of the site has been built with a layer of graceful degradation in mind. If you don't have JavaScript, no problem - you can still use the nav, you can still view video, and any flash components are not core to the journey and are politely hidden from sight. The navigation will need some tweaking to get it fully working on an iPhone, but not much.

To offer a level of interactivity, and to make a break from the tedium of reading through reams of copy, we've introduced video profiles to give an insight into what some Claire's employee's do. To avoid hosting costs, and because it just works, we decided to use YouTube instead of building a bespoke player. By default you will see the video played in full, for example see Glenn Pollards video profile, but you can skip to individual questions from a menu below (our MD's idea, a source of much grumpiness from me, but worth it). Each segment is supported by a transcript for those who are hard of hearing or just sneaking a look while at work.

All drivers are content managed from a central library and all the random seasonal images pull from a set folder. When we want to add the next seasons imagery it will take 5 minutes rather than running through everypage changing individual images.

The homepage features a carousel of drivers, easily content managed, to promote urgent roles and key content in the site. To make it flexible there are different driver types - big image with a link, big image with text and a link (two layouts), or a flash box (with an image fallback). Watch that space for some creative promotions in the future.

Online application - of course one of the biggest parts of the old and this site is the ability to apply entirely online using ThirtyThree's very powerful, and all ours, Applicant Tracking System. And if you don't find what you want today you can sign up for job alerts - forgotten your password, that's a new feature too (surprisingly!).

What else? A global search, links to the many European sister sites (Claire's a transnational company btw), site help, application help and a plan to roll this site out across Europe.

Perhaps the most exciting part of this project is Phase 2. I can't tell you much, it's a big secret at the moment! What I can say is we'll be trying something that, to my knowledge, has never been tried in the recruitment comms industry before. Fingers crossed it'll be a rip-roaring success and we'll be seeing some big accolades for Claire's Careers and ThirtyThree.

10 Tips for Providing Great Customer Service to Your Clients

10 Tips for Providing Great Customer Service to Your Clients

I couldn't agree more.

Image has nothing to do with article.

What a day

Phew, what a day!

I've been reminded of a few classic lessons (not all of them have happened today).

• Always pass the designs through a developer before the client sees them (always strive to acchieve the near impossible but never promise the actually impossible!), 
• COMMUNICATION COMMUNICATION - not delivering the impossible dream is only a downer to the client if their expectations haven't been managed. Manage them!
• And assume they are idiots, you might think you've communicated, but have they understood it... follow calls up with an e-mail (never rely on e-mail), invite them in, have a chat, draw them pictures, tattoo it on their head!
• Chinese whispers never work - cut out the middlemen, speak directly to the horse.
• Walk in their shoes - and then walk in the audiences shoes... what the client wants and what their audience want are often different (help them to see this; user centered design makes sense but telling the client they are 100% wrong doesn't... it's a delicate balance).
• Eat the elephant.
• Pay peanuts get monkeys.
• Feel the force luke!
• Don't become the poo in a poo sandwich.
• Remember the triangle: Quality, Time, Budget - reduce one and the other two will have to compromise. Sorry, that's life!
• Be confident - if you aren't sure that's ok, just be confident, find out the answer later. Don't make things worse by letting them think you're clueless.
• Have breakfast, don't skip lunch!

Cost

A colleague came to me with a problem. The client had asked for a advert to be created, they reviewed it, signed it off, and at the last moment said they didn't like it. So we need to do a new advert for them. My colleague was trying to decide if we should discount the old work, or the new work as we're using a contractor.

I explained that if you built a house for 300K, and at the last moment your client decided not to move in, you wouldn't then charge them 250K just because they aren't going to use what you've made. If they said they wanted another 300K house, you wouldn't then build that for less if it's still worth 300K.

My colleague is still discussing with other people if she should discount the work.

Why is it that people sometimes think web-work doesn't have a value. If you ask for work you should pay for work; if you choose not to use it that is not my problem. I'm of course happy to create something brand new for you.

(Of course in this scenario we are talking about brand new work. I wouldn't be so evil to not offer a discount if there was the possibility of salvaging some of the work from the first house/advert).

UN sustainability campaign wins best website award

I'm very pleased to see that a little website I worked on earlier this year has won an international best website award. http://www.unep.org/Documents.Multilingual/Default.asp?DocumentID=647&ArticleID=6761&l=en 

web accessibility guidelines

Has everyone heard?

"The World Wide Web Consortium (W3C) has announced a new standard to make sites more accessible to older and disabled people.

Version 2.0 of the Web Content Accessibility Guidelines (WCAG) will apply to text, images, audio and video."


http://news.bbc.co.uk/1/hi/technology/7789622.stm

This will give digital agencies plenty of excuses to sell in updates to previous work.

One of the things I think is a good money making idea, but also a good general idea "In particular, the draft standard recommends the involvement of disabled people in the development of websites and suggests automated tools to test for accessibility." - i.e. getting disabled people involved in user testing.

By the looks of it we should be working towards BS 8878 as well.

Life after launch

Just a minor project management nugget today.

It occured to me that when costing and planning a project it is easy to do so up until launch. But websites have a life after launch; that's why you build them! You need to pre-empt this life. For example, if you're building a competition then you need to think "does it expire, will they want to take it down, extract the database, send a mail-out" etc - and of course "how much will that cost?"



Other questions you can ask, do they require ongoing support, training, back-up and archiving, access to stats, stats analysis, further development, do they expect a warranty period, would they want an SLA, etc

Speedo

It's Speedo's 80th year, and they've marked it with a number of micro-sites my agency has been working on: http://www.speedo80.com/hub/

And I've just launched a whole bunch of games I've been project managing for them as one of these microsites: http://speedo80.com/lzrtrials/

Do better

I had a bit of an internal chat today about me. All very complimentary (of course) about how I'm very good at grasping top level stuff, seeing the bigger picture, understanding business needs, requirements, process. Of course (as is the nature of a sandwich) you have to put some criticism in, and it's that which is ultimately going to be the barrier to the pay rise you're after.

The advice I was given, and it's good advice. Is to focus on the granular detail and not just be aware of the top level. It's good to have respect, but you need to have trust too.

Good ways to manage this is to keep a prioritised list, (which I do) but make sure that the small stuff you deem unimportant isn't left so long it becomes important.

A late one once in awhile is a good thing, an extra 10 minutes a day to knock a few things out can save you a heap load of time.

Manage expectations, don't forget that your colleagues are "internal customers".

elephant vs mouse

Interesting article on Ecover today. http://www.treehugger.com/files/2008/07/ecover-eco-factory.php

 

What is interesting about it is that it's a green product, trying to do good and completely in line with my personal philosophy that the only way we're going to do good is if it can also be profitable.

 

What's interesting is that everyone likes to focus on the negatives of a nasty polluting organisation, but also, everyone wants to focus on the negatives of a lovely eco brand like ecover (such as 1 non e friendly chemical).

 

In the article it uses the example of a mouse on an elephants bottom. Let's not focus on the mouse until we've addressed the elephant. And I completely agree. Why is it that journalists have a compulsion to report and we have a compulsion to find interesting negatives, even on those trying to do good? If wind-farms require oil to lubricate the turbines, or a hybrid isn't as efficient as a smaller run around, or if a famous environmentalist takes a ride to a conference on a plane we all focus on the negatives and forget (seemingly) the good.

 

Perhaps it's because the brands are built on squeaky clean eco lovliness and we feel our trust is violated, or perhaps we just like seeing do gooders mess up?

 

But the thing I definately like is the elephant.

 

Ok, we can bitch about hybrids not being as efficent as they could be, the expensive and dangerous chemicals rechargeable batteries use, the inefficicency of certain solar power, etc, etc - but at least someone is trying, and at least it's better than nothing. Of course I guess if there was no consumer demand for eco-perfection then the manufacturers wouldn't strive to improve?

How to scrum

Interested in Scrum, then I suggest you read (and buy) this - http://www.infoq.com/minibooks/scrum-xp-from-the-trenches. It's so incredibly informative about one person's approach to Scrum/Agile. It's an easy read which I completed in a couple of hours and covers most things you'll need to know to successfully run a Scrum project.

Contact reports

A great tip for writing contact reports is to write them in the meeting (if you can). Just whip your laptop out, open up a contact report template, and fill it out as you go along. You then just need to tweak it later (if you take good notes) and can send it out.

And yes, they are useful, and invaluable when a client changes their mind later on.

Contact reports

A great tip for writing contact reports is to write them in the meeting (if you can). Just whip your laptop out, open up a contact report template, and fill it out as you go along. You then just need to tweak it later (if you take good notes) and can send it out.

And yes, they are useful, and invaluable when a client changes their mind later on.

Costing

It's so easy to miss stuff when costing, you might think you've remembered the project management, the IA, the developer, the moodboards and interface design, but whoops, I forgot about QA, upload, I forgot about a few key documents which while they don't seem much still add several days on to a project.

The solution is to add to and always use a checklist. This checklist will be a list of everything you could possibly need for any project ever, and you ask yourself on each item ... do I need this? If yes, what times, what resource, and you build your estimate up with this.

MoSCoW

I've given myself an aim of learning something new everyday. Today I'm posting about MoSCoW

MoSCoW is a method that is used in business and particularly in software development to get an understanding with the customer on the importance they place on the delivery of each functional requirement. It originated as part of the Dynamic Systems Development Method. Sometimes called a MoSCoW list or a MOSCOW Analysis. MoSCoW stands for:
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but WOULD like in the future.

(Source wikipedia)

Just to confirm, a must priority is a showstopper, a project failure if not executed.

“Must
Anything labelled as “MUST” has to be included in the project delivery timebox in order for it to be a success. If even one “MUST” item is not included, the project delivery is considered a failure. “MUST” is also an acronym for the Minimum Usable SubseT” from wikipedia.

To put this in context if we take one of the items, RSS feeds, its reading if BCC cannot offer RSS feeds of community users’ blogs, you view the project will have failed.

The MoSCoW prioritisation process is to weight the requirments to assist in executing the project. It would be great if we could have a chat and go through these. Mainly need to get a bit more balance across the prioritisation.

(source - wikipedia and someone I work with)