Friday, December 7, 2018

Still making the same SEO mistakes?

I'm amazed that so many existing & newly
-developed websites are still making so many Search Engine Optimisation mistakes. It seems to me that so many organisations are ignoring the basics when it comes to organic improvement of their main online asset.

I see it time and time again:
- Poor keyword analysis
- Unrealistic placement targets
- Poor quality coding
- Duplicate (or very similar) content
- No redirects for deleted pages
- Badly written content

Why is this?

Friday, November 9, 2018

Site launch checklist

I was recently asked for a checklist of essential items to check on a website before it launched. So I have shared it with you all here:

Page titles
You should know by now that every page must have a page title. It's what appears in the top of the browser for that page and how it gets shown by default as a bookmark or Social Media post.
However it is also a key Search Engine Optimisation ranking factor, so ensure that it is relevant, the right length (approx 55 characters including spaces seems to be fine) and ideally unique across your new site. There is also a significant consensus in the SEO community that the keyword you are targeting for this page should be as close to the beginning of this title as possible.... but I will leave that for you to assess the value of.
Also since Google usually displays just the first 50–60 characters of a title tag, I would keep to that range without very good reason.

Meta data / Meta tags
These have grown in the number and function they perform over time, with some having a bearing on Social channels and SEO. But the key one here is Meta Description.
I'm not going to give you advice about what to exactly write in this field... as I've covered it in so many other blog posts. However, ensure that have a description on every page (correctly placed inside the <head> of the page). Plus consider that the current average length of the description field for desktop results is around 160 characters, whereas an average of 130 characters for mobile seems to be the best.
Note: Ignore using Meta Keyword tags

Sitemap
This little text file (mostly named sitemap.xml) usually sits in the root directory (or obvious sub-directory) of your site. It is a tried & tested way to tell search engines which pages are available for them to be crawled. It does this by giving a list of URLs for every public page in the site along with extra metadata about them.

Robots.txt
This little text file (all lower-case only please) should sit in your root directory of your site. It is usually the first file a search engine bot checks on a site and is there to tell all or individual bots what they are NOT supposed to do. For example, they are supposed to ignore certain directories or files.
So in this way it is the opposite of a sitemap.xml file and care should be taken to not have pages in both.
Note: some search engines may ignore the robots.txt so do not use this as a way to  hide site content or data you definitely don't want found.

Redirects
When launching a new site, URLs can change.
At the most fundamental level, this can mean a change of domain (e.g. brandx.com to brand y.com) or a change of sub-domain (e.g. blog.brand.com to brand.com/blog). So sites should ensure they understand and handle all redirects correctly at new site launch.

Wednesday, October 31, 2018

Minimum Viable Experimentation


Those who work in the digital and agile world should be pretty familiar by now with the implementation of a Minimum Viable Product (MVP). This is the creation of a working product that doesn’t have to meet all requirements, but allows further testing, feedback & iterative improvements. It is an approach pretty well understood and used across the industry and one that should lead to better products sooner.

So perhaps we need to use this approach, not just in the creation of the initial product, but in the way we release further functionality & features to our products? This would mean focusing less on the usefulness what each new piece of functionality provides (in economic terms the 'utility'), but basing each successive development on what it tells us about the product's overall ability to meet the wider strategic objective?

In other words, rather than add new stuff that simply compliments the overall richness of the experience... shouldn't each new tangible delivery be based upon a hypothesis? And in-turn, shouldn't this hypothesis be derived from insight that is focused on improving the user's needs or outcomes?

For example... if your project aim (which I assume directly linked to your strategic objective) is "to have a better online sign-up process for a new credit card", then each successive sprint or release from the initial product launch should be delivered to address this aim. However you shouldn't just assume that this is the case. 

Firstly make sure that each time you plan your deliverables you are actually answering a question, such as:
"How can we stop [a specific type of customer] exiting the online form before the end of the process?"

Secondly develop a hypothesis that can be tested in a small experiment. Such as:
"We believe that by adding [1: a specific feature] at [2: a specific point] we will create [3: an expected behaviour] by the user and therefore they will reach [4: an outcome] that will improve [5: a goal]."

Where in our new credit card sign-up example this could be:

1
A specific feature
A reassuring statement about financial approval
2
A specific point
The 4th of 5 pages in the process, where the most users drop out
3
An expected behaviour
The user is reassured that they could be approved easily
4
An outcome
The user moves to the 5th (and final) page of the process
5
A goal
Form conversion improves


It is worth stressing the point that these experiments don't have to be huge or complex, and in some cases making changes to a piece of content or image may be sufficient. They just have to be enough to prove or disprove your experiment's hypotheses…. a minimum viable experiment and nothing more.

Tuesday, October 30, 2018

What question are you really trying to answer?

Agile
Digital Transformation
Self-service technology
Faster delivery
<yawn>

Heard it all before? Yes, so have I... numerous times and across many different clients.
Each is craving to "move to become a digital organisation" or "reinvent their online proposition to embrace change" and other similar modern and (to be honest) pretty meaningless statements about themselves.

But I think they are approaching this the wrong way. 

On the basis that each company exists to provide a product or service to another (person or company)... why the heck are they not focusing on asking more questions about what their customers need? Or questioning what stops their valuable users buying/using/engaging more? And more fundamentally... why aren't more people tasked with trying to answer those questions with the creation of better products and services, increasingly delivered as software?

So rather than saying "we need to redevelop our website to improve our KPIs"...
You need to ask "why don't we make it easier for customers to convert?"

And rather than stating "we need to reduce the number of clicks in our online booking process".
You need to ask yourself "why do customers seem to have a problem getting past the 4th page?"

It is only then that you get to the creation of an insight-based hypothesis to change a process or product. 

Friday, October 19, 2018

Is data driven marketing that simple

In a Linkedin.com post recently I commented about the increased adoption of data driven marketing ...

It's simple really:
1. Build insight with real data
2. Foster loyalty
3. Communicate creatively
4. Analyse to improve

But is it that simple?

Friday, October 12, 2018

How HCI and API design are similar

All software needs an interface. Having one makes it possible to use the functionality and consume the data that lives within that software.

Humans use interfaces for software all the time, with the World Wide Web arguably being the biggest interface there is (OK, perhaps some websites aren't the best examples of usefulness in this mass experiment).  But put basically... they allow human-to-system interaction, also known as Human Computer Interaction or HCI for short.

Human Computer Interfaces have the following principles:

  1. They remove complexity:
    By making it clear what each function does (e.g. do not have two ways of doing similar things)
  2. They follow standards:
    By following established conventions (hyperlinks, buttons, tick boxes, etc.) they provide consistency.
  3. They make interaction easier:
    By enabling swift and efficient relationship with the underlying data & processes and providing feedback or a response when something happens.

And Application Programming Interfaces (APIs) play a very similar role, but in a slightly different system-to-system manner. They:

  1. Remove complexity, by (hopefully) providing a single request & response for each individual function
  2. Follow standards, usually in the form of an API specification, to allow consistent development against them
  3. Make interaction with the underlying systems easier via a standard set of methods (GET, POST, DELETE, etc.)

Ultimately, whether interacting with a human or another system... a well designed interface benefits both parties.

Wednesday, October 10, 2018

Behave, Deliver and Grow Like A Digital Company

Delivering digital interfaces to your organisation's customers, partners and employees is no longer optional. It is now essential for long-term effectiveness (and survival).

But this means unlocking the data, systems and functionality your business operates with and exposing this both internally and externally to meet increasingly shifting needs. But it is not easy... hardly any sizeable company has an entirely blank slate to work from. Legacy applications, processes and thinking tie any business down so that it can work well. But it is these very constraints that often limit speed and agility, which are needed to succeed now.

Digitally enabling your business means changing the way you behave, deliver and grow.

Behaviour:
Being customer focused means creating a better customer experience that can win and maintain custom in the competitive digital landscape. It also means understating and controlling your data, so you to make informed decisions quickly based on what you are observing or being told.

Delivery:
Start by using new platforms, tools and methods to build products quickly, plus then to evolve them rapidly over time. If you think your quarterly website functionality is fast now, consider that over 7 years ago Amazon stated it makes changes to production every 11.6 seconds (it may even be faster now) and Facebook releases to production twice a day.

Growth:
Don't be afraid to unleash the creativity and innovation within your boundaries to help you build. Employees must be part of the Digital journey (not observers) and everyone, not just your test manager, must work towards the continuous improvement of products and services.