Should you use a developer in India?

January 9th, 2010

With many hi-tech jobs moving to India, should you bite the bullet and source some cheap web development yourself? Let me tell you about our experiences.
At CommOut, we’ve used two Indian development houses. One has been a great supplier and we now have an ongoing partnership. The second experience was a disaster.

In the first case, we listed a Flash animation job on getafreelancer.com. The freelancer we decided to use was in India. The project delivered a successful outcome – our client was very happy to have a great animation for about 10% of the price they would have paid in Australia. The downside was that it took about 3 times as long as it would have with a local developer. This was due to communication difficulties (English is not their first language) and cultural differences. For example, the animation featured western supermarket. As the developer was unfamilar with such supermarkets, he drew what he knew – which was a 3rd world store. I had to supply photos of what a supermarket here looks like so that he could understand what was needed. Luckily, we had plenty of time, so we made the deadline. We would have been in trouble if there was a tight deadline.

So, my first tip is: If you are going to trial an Indian supplier, do it with a project that isn’t time critical. It’s also a good idea to start with something simple.

We’ve since been working with this supplier for the past 12 months. Their turnaround time is now great – the familiarity of working together on numerous projects has certainly helped communication. Communication is mainly via Skype and email – sometimes we talk on the phone, but I really struggle with their accents, so it’s not my preferred method.

Second tip: Give it time & expect to have to explain stuff more than you would to a local supplier. If you try a project with an Indian supplier and they deliver basically what you want (don’t expect to be blown away by the first project) then it’s worth persisting. Develop the relationship and you’ll soon learn the pitfalls to avoid and what they can and can’t do well. Provide lots of examples of what you are after and what you like. Describe in detail what you want (which goes for a local supplier too – they aren’t mind readers either).

Now for the disaster… we placed another listing on getafreelancer.com for the development of some Sharepoint templates. We were doing a Sharepoint Intranet development for a client and needed to bring in the expertise to develop the templates. We selected an Indian supplier who had good references on getafreelancer.com and claimed to have the expertise. Let’s just say that they didn’t… We paid A$3K for a set of templates that took a lot of testing and work on our behalf and that didn’t extend to all the Sharepoint webparts. Yes, it was much cheaper than the $20K we were quoted by a local supplier, but we basically got what we paid for. The Indian supplier was also aggressive and not pleasant to deal with.

Tip 3: If you are looking for very specific technical skills then make sure you get references and call them. Also ask to see examples (if possible). If possible, talk to the developer on the telephone before you engage them to get a feel for their manner.

Finally, it may be difficult to do business with an Indian developer if you working for a large company. Typically, you may them via Paypal or another Internet based payment system. They don’t issue official tax invoices – which will make you unpopular with your Accounts Payable department. In this situation, you may be better off to ask one of your small suppliers to pay them on your behalf and then bill you.
Also, if you are not allowed to have an instant messaging/desktop sharing program like Skype installed on your work computer then communication is going to be difficult. If you are not prepared to communicate outside of your working hours then the time difference will also be a problem. I typically spend 2-3 hours per night on Skype, chatting with our Indian developer. We clarify details, share testing results etc. It’s an efficient way to communicate.

The bottom line is: if you find a good Indian developer you can work with then it’s worth investing the time and energy to build the relationship. The return on investment is high due to their extremely low cost.

Home page images

November 18th, 2009

I’ve come to the conclusion that the wide, narrow landscape images that are frequently used on Home pages are a bad idea.
If you want to actively use that space to promote new products, customer success stories, corporate events etc (and I encourage you to do so – it’s one of the most valuable pieces of real estate in your website) then you will need suitable images to fit that space. The trouble is that you’ll have to wrestle most images into that very landscape format. If you look at the images in your photo library, I’m sure most of them are square or slightly landscape. Getting them to play nice in an area that is 960 px wide and only a few hundred pixels high is hard – without great PhotoShop and design skills. It means that you need the services of a graphic designer each time you want to change the image on your Home page.

A better idea is to make the image area on your Home page more square in shape – using the area on the left or right of it for promotional text or buttons or a navigation aid. It will then be much easier for the graphical dummy to upload an image that will fit.

What to consider in a website audit

November 10th, 2009

A common way for consultancies to get into a company is to offer an audit of a website. Sometimes they even do it for free in the hope of generating work as a result of the audit findings. New managers in a company often commission audits of websites they inherit to give themselves some idea about where to focus their attentions and what is working and what isn’t.
But what should you look for in an audit? Firstly, it needs to be holistic. It’s easy to just focus on one website audience – customers for example. This ignores all the other audiences who come to your site – job seekers, investors, suppliers, government agencies etc. The audit also needs to be holistic in terms of covering both the front end content and functionality of the site as well as the backend system operating it and the organisational politics behind it.

If you commission an audit of your website from a customer/business generation perspective then the auditor will probably sit in front of the site for sometime, going through a checklist of things like “Is the site optimised for Google rankings?” and “Can a customer successfully find and buy item X?” and “How do their major competitor’s sites compare?”. These are all things that you should get right – but is there the organisational will to do it? Do you have executive buy in that the website is important to the business (or do they consider it little more than brochure-ware?) and are they prepared to put resources in place to make it happen?

Inside info
Your audit should include interviews with key people in organisation who use (or should use!) the website. What frustrations do they have with the site now? What are their customers (and we are talking ‘customers’ in terms of the people they support e.g. Investor, not just the company’s customers) asking for? What are the internal politics driving decisions? For example, you might currently have the company’s Business Units listed on the site because the head of each Business wants to see ‘their’ Business unit listed on the Home page. Unless your Business Units actually mean something to a customer, you should not force them to understand your organisational structure in order to do business with you. Getting this changed requires political force and the will to do it. Does your organisation have the will?

Dollars talk
If you don’t have ROI numbers from your current site then get some data by determining what happened to the sales leads that have come in over the past few months (depending on the length of your sales cycle). If you are getting quality leads that generate business (and try not to ask the salespeople directly – they ALWAYS knew that customer before the web lead came in…) then you know it’s worthwhile investing money in the website. If most of the sales leads are duds then you have to ask yourself if they’ll always be duds because of the way your business works or if you can improve the website to deliver quality leads. One company CommOut works with has 4 customers. Period. They don’t need a website that generates sales leads as there isn’t the customer base to demand it. What they do need is a sophisticated collaboration site that allows them to work on projects with their customers – sharing information and ideas.

Getting the dirt
Back to the audit… As well as interviewing internal people, the auditor should also call people who have recently submitted an enquiry/sales request on the website. They have to be called ASAP after the enquiry to make it valuable. How much would you remember about a website the day after you submitted an enquiry on it? The auditor should have a standard list of questions to ask and should cover a cross section of geographic locations and enquirer types.

The auditor should also ask company Receptionists/Call centres. They will often get calls from people who are looking at the website, so can give insight into what people’s experiences are. For example, they might be frequent calls about not being able to find the contact numbers for your company’s offices.

Analytics

An auditor should also ask for access to your website’s analytics or they should offer their own solution. This is another set of data that can be analysed to determine why people come to the site, what they do when they get there and what they achieve during their visit. If your website logs the phrases entered into your site search field then this is also a valuable source of information.

In summary, ask lots of questions before signing up for an audit and consider paying for a complete, holistic audit that will deliver information and recommendations that are truly independent.

Usability – still ignored

July 27th, 2009

I was sitting next to a young marketer at a breakfast seminar recently. The company she worked for was an online business and when she saw my business card she mentioned that they were re-doing their website. I asked if they were including usability testing as part of that revamp. She looked at me blankly.

What is usability testing? It’s the testing of a software interface e.g. a website, to ensure that typical users can perform the functions they are likely to want to do – quickly and easily. You’ve probably experienced poor usability many times. It’s the car parking ticket machine that you can’t work out where to put the money. It’s the website that doesn’t seem to offer any ‘contact us’ information – until you accidently stumble on it 15 clicks later.

It amazes me that usability is still not a mainstream component of website development. The return on investment is incredible, yet it remains a hard sell within a corporate environment. In the 10+ years I was responsible for various corporate websites I would never sell paying for professional usability testing to the executive team. Whilst the concept is relatively simple, the science being usability testing and the benefits of doing it remain a mystery to most. The closest I ever got to ’selling’ usability was being able to rent a usability lab for us to run usability tests in – using an inhouse team.

So, if you can’t get a budget for professional usability testing what should you do? Do it yourself. Some testing is much better than none at all. There are some great books on the topic – a quick search on Amazon will reveal the likes of ‘Don’t make me think’ and of course the guru of usability Jakob Nielsen has a wealth of information at http://www.useit.com/.

Usability testing subject selection is important to get right. I recommend asking one of the executive team to participate (if only to show them the benefits of testing!). Choose as wide a cross-section of age, gender and nationality as you have time to accomodate. If you want support for change within the organisation e.g. you are doing an Intranet redevelopment, then also choose those loud complainers in the testing – they will then feel like they contributed to the redesign and will be more likely to support the change.

If you have multiple audiences you are catering for on your website then try to make sure each group is covered. For a B2B site this might be: end users, installers, specifiers, Channel partners etc. Or it might be new customers, existing customers, channel partners and investors. For an Intranet, try to cover the spectrum of employee diversity – Gen Y through to Baby Boomer, male/female and the various nationalities your company includes.

List the top 3-5 tasks that each audience group might come to the site to do. For example, an existing customer might come to your website to download the latest software driver for your product. A new employee might come to your Intranet to find the company templates or to read the Leave policy.
Here is an example of some usability tasks we used to test the navigational structure of an Intranet:

You are a salesperson within .
1. You want to order some corporate gifts for visiting customers.
2. You want to apply for leave – how will you do it?
3. You need some help with , determine what training or instructional resources are available.
4. You need to do some research on market trends. What market research tools are available to you?

For an ecommerce site, you would ask the test subject to purchase a specific item (particularly one that you have doubts about where it sits on the site or how it’s described) or to figure out how to return a purchase.

Provide the test subject with a printed list of the tasks they must achieve. Sit beside them with the same list and a note pad. You can time how long it takes them to complete each task if you wish. This is useful if you are doing iterative testing of different designs.

Ask the subject to attempt the tasks on the list. If you don’t have a test website to use then create a mock-up in Powerpoint and ask them to use that. You can even use a paper mockup.

The key is to get them to tell you what they are thinking as they attempt the tasks. Remind them to verbalise their thoughts. Use prompts like “What word are you looking for on the screen now?” or “What were you expecting when you clicked on that?”. You’ll have to keep reminding them as they get absorbed in the task.

The other thing you CANNOT do is help them. Resist the temptation to wrench the mouse out of their hands to ’show them’. If they can’t proceed with a task, note this and ask them to move onto the next one. You’ll then know that you have some serious redesign work to do in that area.

Typically, you’ll find that the different test subjects stumble in the same places. This is an easy re-design win. The hard ones are when most test subjects complete a task but 1 or 2 don’t. Then you need to decide if they are representative of enough potential site visitors to worry about.

A final tip: If you are working with website developers who remain unconvinced of the value of usability testing then ask them to sit in on the testing or video record the sessions to show them. You may have to restrain them from ‘helping’ your test subjects, but the sessions will get you great support for design changes they might have otherwise resisted.

Usability is critical to the success of a CMS

July 4th, 2009

I’m currently using three different content management systems (CMS) /collaboration systems across different projects. Their ease of use varies enormously – from the frustrating Lotus Notes QuickR that seems to designed to be as cryptic as humanly possible and demand 15 clicks for the simplest of tasks.
Next on the scale is Microsoft Sharepoint – MOSS. As a content management system it’s OK, not fantastic, but OK. It’s much easier to use than the QuickR system – as a collaboration tool, most users seem to pick it up easily and its tight integration with MS Office makes things easier. It is a good choice for an Intranet as the collaboration tools mean that it will be adopted warmly by users as it makes their life easier. I wouldn’t recommend it for a corporate public website that has multiple editors contributing content.

My favourite in terms of usability is Clickability’s CMS. It’s logical and all the users I’ve trained on it (across multiple countries and varying levels of English skills) have found it easy to use. Two of its best usability features are: editor profiles and customisation of content entry screens.
Editor profiling is the ability to tightly control what each Editor has access to in terms of content and where the content goes. This means that the number of options they are presented with is limited (reducing confusion) and can be customised to suit their job role. For example, several Editors are within the company’s HR function and only use the system to list job opportunities on the website. When they login they only see the ‘job opportunities’ content type and they can only save their content in one place. They love it. Even if they don’t use it for sometime they can figure it out easily when they next log in.

Clickability also allows the content entry screen for different content types to be completely customised. You can even customise the hint text that appears next to each field. For example, when entering job opportunities the Editor is presented with a form that asks them for only the information that is required: job title, description, location, etc. If they are entering information about a new product then they select the template for that content type and fill out the form that asks them for the product title, description, uses, geographic availability etc. These forms are completely customised to suit each different type of content.

The key message is that you need to put usability high on your list of requirements when evaluating content management or collaboration systems. Ask for a trial site you can play around with. Get someone representative of a typical editor to perform some specific tasks within the trial site – watch where they stumble, ask them what they think the choices presented to them mean.
Ask the referees you call how easy their editors find the system to use and how much support their administrators have to do. Send a message out to your personal network (LinkedIn.com is great for this), asking if anyone has experienced the system(s) you are considering and how easy they found them to use. A little bit of investigation prior to implementation will save you a lot of heartache afterwards!

Corporate cobwebs

June 5th, 2009

Most corporate websites are released with much fanfare, after considerable investment. Being one of the most public faces of a company, it’s important to get a website right, so investing lots of time and money into its development is necessary.

Where things often go wrong is the ongoing maintenance of the site. Typically, the Home page and press releases are up to date, but much of the deeper content, the product /service listings and support information are woefully out of date/inaccurate in a relatively short time. This results in the typical lifetime of a corporate website being 2-3 years, at which point the site is redeveloped all over again because it’s deemed to be out of date (see considerable investment above).

The ongoing maintenance of a website should be included in the project plan right from the start. It’s one of the questions CommOut asks during the first project meetings with clients: “How will you maintain this website?” Typically, it comes as a surprise to the client.

Here are three tips for maintaining a website :

1. Design the website so that maintenance is easy. This means having content that is likely to change in one place – not multiple places. A good example is contact information for your offices/sites. Keep the address and phone numbers for your sites in one content item (or on one web page) only. You can pull that content into other webpages dynamically if you design the website that way. This means that when the contact details change, you only have to update them in one place on the website and it changes across the whole site.

2. If you are implementing a content management system (CMS) then ask if it has functionality that will allow a review period to be set for each piece of web content. The CMS will then automatically email the owner of that content when the review period is up – prompting them to check that the information is still up to date.

An example here is company performance data. If you are a publicly listed company then chances are that you have financial information that has to be updated at least each 6 months. By setting the review date for that web content to coincide with the release of financial results to the market, then the web editor will get an automatic email reminding them to do it.

3. Resource your website properly. Gone are the days when a website could be ‘a job on the side’ for the Communications or Marketing Manager (who already had a full time job!) or could be left to someone in IT to maintain. If your website is critical to your business then make sure that you have the staff in place to manage it. They need to be assertive enough to bug the knowledge owners in the organisation e.g. product managers, HR, the support team for information to update the site. They need to research and recommend ways that the website can be used to bring in business, reduce costs or meet other business needs. They need to ‘own’ the company’s online presence.

If your website isn’t critical to your business (a good way to test this is to ask yourself what the impact of the site being down for a week would be) then include responsibility for the company Intranet and perhaps some other online tools e.g. an image library, customer database (like salesforce.com) in the job description to create a role that has the online world at its heart.

Web content in multiple languages

May 19th, 2009

For most multinational companies, providing web content in multiple languages is a huge burden and expense. With translation costs typically being about A$0.40 per word per language, translation costs quickly add up. There are several decisions to consider in the process:

Whilst your customers might reside in multiple countries, does their profession dictate that they have good English skills? For example, they might be scientific researchers who operate in a niche area that requires collaboration with other researchers across the world. Highly likely that they’ll have good English skills. If they are your target market then you may not need to translate your website.

If this is not the case and you need to provide local language content to generate leads or provide support then consider if you need to translate the whole site or just part of it. It’s often the case that your regional offices really just want a local language web presence that allows them to promote local activities etc. This can be achieved with either a small subsite in local language (rather than the whole site) or the nifty trick we did for the amcor.com site (link) where the language switch only appears on specific pages and only the main content of the page is translated. By using a specific url e.g. www.amcor.com/pharma-brasil in their offline marketing (and in email signatures etc), Brazilian customers can be directed straight to content in Portugese.

Regulatory requirements of different countries often dictate that you offer local language web content if you do business in France or operate a country-specific domain. France is the well known example. If you have the domain name www.company.fr then redirecting it to the English .com site isn’t going to cut it. A site visitor could reasonably expect that the .fr site would be in French.

If your industry is heavily regulated e.g. pharmaceuticals, fire protection, banking, then you may need to ensure that the local language versions of the site say the same thing as the English version. In this situation – it’s wise to implement a full translation management process to ensure that all your site is up to date in all languages. You don’t want to have your English version saying one thing, German another and Spanish another, leaving you open for non compliance. A content management system that does the hard work for you in this area would be a worthwhile investment.

The design of your site’s language selection is also important. You have to design the site assuming that a site visitor cannot read English at all. This means that having a drop-down menu with the English words ‘Language selection’ beside it is not a good idea because the visitor may not be able to read ‘Language selection’. Having a list of the available languages, all visible when you first land on the web page and with the name of the language in the language itself is much better.

Here’s an example of poor design: http://www.xtralis.com/ If you click on ‘International’ then you get offered a link to their Chinese language… in English. If a Chinese-speaker landed on their Home page it would be unlikely that they would find their way to the Chinese site if they couldn’t read any English.

Using flags as language-selection devices are also a bad idea because many countries have more than one official language, so it’s not a one-flag to one-language relationship.

To become more empathetic to your non-English speaking users, visit a website that is in a language you don’t speak (try one that doesn’t use the Roman alphabet for the ultimate challenge) and see if you can find your way around. You’ll quickly see how hard it is.

Another area to consider is how to convey which products & services are available in which countries. Don’t waste your site visitor’s time by getting them all excited about a product just to dash their hopes when they find out it isn’t available in their country. On the Amcor.com website, each product is tagged to indicate where it is available (example: http://www.amcor.com/productSearch/?submit1=Search&2921=142736). This cuts down on a lot of poor quality web leads for products that can’t be supplied.

Stakeholder consultations

May 6th, 2009

We recently completed a Sharepoint 2007 (MOSS) Intranet redevelopment. During the project we conducted multiple consultations with the various departments and individuals in the organisation.
The questions asked are contained in this document: Stakeholder Interview Questionswhich might be useful if you are developing an Intranet. The questions are skewed for a Sharepoint implementation – focusing on collaboration, but adapt to suit your needs.

Do you need a CMS?

April 28th, 2009

As more companies become aware of content management systems (CMS) it’s becoming a must-have tool. But do you really need a CMS?
It depends.
One of our clients was recently quoted A$80K to have a website developed that included a CMS.
When we stood back and looked at the situation holistically we found:

  • The site was a relatively small brochure-ware site of less than 20 pages that was unlikely to grow too much over the coming years as it is not a core part of their business
  • The frequency of updates to the site was likely to be low as their products were very stable and they were planning on creating a separate ecommerce site using the MS Dynamics ERP system they were implementing as part of a different project
  • The person looking after the site had good IT skills and anyone in that role in the future would be likely to also have that level of skill (and they could certainly include that in the recruitment process
  • They already owned several Adobe products such as InDesign and PhotoShop and weren’t afraid to use them

Our recommendation was NOT to have a CMS (gasp!) but to use Adobe Dreamweaver as the tool to manage the website on an ongoing basis. This reduced the price of the website to about 1/4 of the price they were quoted by the other company.
While we built the site, the person who would ultimately have responsibility for managing it attended a Dreamweaver training course. We are preparing a documentation suite now and will use this to train the site editor when we hand over the site to her.
It’s always good to use the documentation as the training tool. This allows you to usability test the documentation itself and it teaches the trainee that the documents are a good place to go if they get stuck. Having effective documentation is good from a process sustainability perspective too. When it comes time to hand over the responsibility of the website maintenance to someone else, the website editor can just hand them the documents as “here’s the manual on how to update the website”. Once they have the website files and the documents then they are good to go.
Of course, it does mean that you have to create good quality documentation – but more on that later.
So, the outcomes were:
The company got a website for considerably less than they were expecting
The person responsible for managing the site expanded their skill set, which pleased them personally
The right tool was selected for the job – instead of using a sledgehammer to crack a walnut

If the situation had been different – with lots of content and multiple editors, then yes, a CMS would be appropriate. But a CMS is not always the right solution.

What’s this all about?

April 28th, 2009

CommOut is an online marketing consultancy in Melbourne Australia. We specialise in helping business to business (B2B) companies use the Internet to build their brand, generate sales and keep their customers happy (usually by offering great support).
This blog chronicles the things we learn as we help our customers – the things to avoid, the things to adopt and the things to consider if they are right for you.
Our customers range from the very large – like multinational packaging company Amcor to the boutique, like GMP regulatory consultancy PharmOut.
Yes, we’ll be revealing secrets and making things like checklists and templates available. All that good stuff that you can take and implement for your own purposes.