What Developers Can Learn from Google and SEO to Build Better Apps

SEO Lessons For Developers
SEO Lessons For Developers

For the past year I have been working to improve my own personal organic search profile and have started helping clients do the same.

Don't worry I am still a web developer, which gives me a unique insight into both disciplines.

One reason why SEO has become so attractive to me is the advantage knowing how to build high quality websites gives me. At the same time, I have studied and how online marketers approach their craft.

At this point I feel there are many lessons developers and devop engineers can learn from their online marketing counterparts about software development and delivery.

No, I don't think marketing folks can add value to the coding details specifically, but more what developers should consider about their applications and how they relate to the end user.

What marketers and stakeholders can drive is product quality.

Yeah, expectations can be a bit crazy at times, and both sides can be the cause. Trust me I have seen more than my fair share of insane product expectations over the years.

SEO For Developers on DotNetRocks
SEO For Developers on DotNetRocks

You see, marketers need a product experience and quality they can feel confident about so they can sell it. When they sell the product the company makes money and of course developers get paid.

The good news is there are best practices the technical side of the house can follow.

Be sure to catch my interview with Carl Franklin and Richard Campbell on the DotNetRocks podcast. We have a great conversation about why developers should care about SEO and what they can learn about development best practices from SEO.

A key point I tried to emphasize in the conversation is what Google tells us about what works and does not work based on the data they collect. But are developers listening and do they attempt to apply the Google advice to their applications?

Lessons From Google

Marketers are obsessed with target markets and what Google says to do and not do.

Note: If you take anything away from this article take this: Google collects and analyzes more data than probably any organization on the planet. It is their business to know what people like. When their search, web trends or Chrome team shares a best practice you should pay attention.

My experience is most developers are not very concerned with how their application user interfaces are perceived by real users. If they were then books like Why Software Sucks would not exist.

Most developers are not front-end developers, they are back-end developers and focus their energy on designing 'hard logic' using code. The bits the end user is insulated from.

This creates a disconnect that makes most software stressful to use. When a customer is stressed this means the company is not making money, even when it is an internal application.

A company makes money by selling products and services as efficiently as possible. Software developers should understand this and work to make this happen.

Unfortunately, when it comes to the actual user experience development teams treat this as a 2nd class citizen.

To paraphrase Billy Hollis, if there is not code involved, developers don't care.

So how can developers learn user experience best practices from Google?

Google Daily Search Volume
Google Daily Search Volume

Google processes over 72,000 search queries per second.

That means they collect a universe of data every day. That data is on what people want and like. So, they have credibility like no one else.

They analyze this data and share a distilled version of this information with us. They try to tell us what best practices we should apply.

They also try to share with us, without disclosing proprietary information about the 'search algorithm' works.

Google needs and wants the best content to be available at all times. They try to help us.

So listen to what they have to say.

Ignoring their guidance is a mistake. Lessons from online marketing should be taken into account for all websites and applications.

This is why developers should pay attention. Even when you are building a business application that won't be indexed by a search engine, the user experience metrics still matter.

I have taken the time to highlight a few areas I have observed SEO leaders and Google's search relations team emphasizing to their audiences so they can be more successful online.

Understanding User Intent

When creating content for organic search marketers know they need to research not only what people are searching for, but what sort of content are they choosing.

When creating business applications developers need to follow this principle because it will guide them toward creating an application the target audience will want to use.

Instead of creating applications users have to use, create applications they want and enjoy using.

Think about it, are you creating an application for your (the developer's) pleasure or are you creating a tool to solve problems efficiently?

Of course you are creating a tool to help your customer more efficiently solve a problem. That problem could be data entry, access or manipulation. Or maybe its a marketing tool, like a site that need organic search exposure.

What is their goal? What are they really trying to solve?

This is why I like interviewing real users as much as possible before crafting a new user interface.

I want to get into their mindset as much as possible. I want to know where they currently feel pain, and make it go away as much as possible.

Competing in business is difficult. What can separate two or more competing products or services is the ability for end users to just be able to use the software and solve problems with as little friction as possible.

Far too often I, and I know you, have to use software that was just poorly designed. Think about any cell phone, cable company or government website.

You just want to get away as quickly as possible.

The interfaces are not only outdated, they are difficult to use.

The good news with the web is it is easy to iterate and improve, assuming you have a good architecture with clear separation of concerns and modular components.

And iteration may be the key because good software is never complete. You keep changing it based on continuous feedback loops.

Software Continuous Improvement Cycle
Software Continuous Improvement Cycle

Search engine optimization works much the same. Marketers need to publish content and continually follow up to see how well it ranks, attracts and retains traffic.

They also need to test what leads to conversions and what doesn't. They know they need to test theories out and be willing to trash them when they do not resonate.

Google uses these signals to help them rank content for search results.

For the enterprise and hosted applications, the concepts of good, targeted user experience driven by user intent or goals is a fundamental principle that I often find missing when I consult in enterprises.

We often make the mistake of creating a UI based on how we, the developer would use it. One of the many problems is we know where the land mines are and how to walk around them.

This means we create a fragile and often frustrating UI. The overall user intent is not the focus, it is what is best for the developer, not actual user.

You must create software that makes it easy for the customer to achieve their goal, even when that goal is an internal business process.

Making a Good User Experience Through Technical SEO

While somewhat subjective, user experience comes down to science. It is a science based on observation.

For example, we know 100ms is the threshold to perceive an action as instant.

1 second is where our mind starts to lose focus and by 3 seconds most have given up on a page rendering.

For SEO that observation does not even need to require directly observing real people, you can survey sites that rank well and drive traffic.

If they are earning thousands and even millions of monthly visitors, then they must be doing something right.

This is more or less what Steve Souders and his team did over a decade ago when he published the book High Performance Web Sites.

They analyzed what were common technical things the most popular sites were doing average web sites were not.

The goal was to provide a set of best practices we could apply to our sites to improve user experience by improving page speed.

Fast forward to today and the average web page takes 22 seconds to load, several times slower than a decade ago.

Did we ignore Steve's advice?

Well yes and no.

His list of best practices were best practices back in 2008. Most still are, others have been replaced with platform improvements, like HTTP/2.

What has happened in the last decade is the explosions of mobile and JavaScript.

The combination of consumers adoption a mobile first experience and developers obsessing over using more JavaScript have created very slow pages.

This lack of speed is killing user experience.

And this leads to the next main point, being mobile first.

Build Mobile First

I already mentioned consumers have migrated to use mobile devices more than desktops. Google has noticed as well.

Over the past year they flipped their primary search index to their 'mobile first' index. They have been migrating sites to this index as well.

When you use Google tools like the Search Console or Page Speed Test you are seeing data using the mobile experience for the site. Some of the tools don't even let you test the desktop experience.

Almost 70% of Google's searches are done using a mobile device. This should not go unnoticed by the enterprise.

Where consumers are, enterprises follow, even for business applications.

I know, I know, enterprises were going mobile years ago. I even built an enterprise mobility platform way back in 2011.

Trust me it was cool, just poorly executed from the business side 😎.

Several years ago Jason Grigsby wrote about a common problem enterprises have about their software:

"Any attempt to draw a line around a particular device class has as much permanence as a literal line in the sand. Pause for a moment and the line blurs. Look away and it will be gone.

Let’s take the absolute best case scenario. You’re building a web app for internal users for whom you get to specify what computer is purchased and used. You can specify the browser, the monitor size, keyboard, etc."

What Jason was discussing is almost an arrogance the enterprise IT department has thinking it controls the environments their applications are used.

They don't, at least not anymore.

This creates challenges for software development and hosting. You have to assume a hostile environment for your user experience.

This is why a mobile-first approach gives you the best chance to succeed. Doing so forces you to design for all client environments.

Be Mobile First
Be Mobile First

This means you need to employ responsive web design best practices and be aware of technical SEO best practices, like page speed.

You should start by including a viewport META tag in your page HEAD:


<meta name="viewport" content="width=device-width, initial-scale=1.0">

From there make sure you apply good responsive design coding practices. For most of us CSS libraries like Bootstrap have built in responsive layout grids.

This of course makes RWD easier to implement. But it still takes planning because responsive design is about more than resizing and moving elements around the screen based on viewport size.

You need to apply good spacing practices, make sure touch points are easy to access with fingers, not just a mouse pointer.

Just using properly sized buttons and read-able fonts can go a long way to reduce data entry errors.

For design needs to be clearly thought out as well. Today we have a series of modern input types to help trigger on screen keyboards, formatting and validation. Each of these features make mobile useage better.

Yet most forms do not take advantage of these modern features, despite them having ubiquitous support by browsers for almost a decade.

And don't forget about accounting for voice input.

Create a navigation experience that is easy to find site assets, etc. Believe it or not, bad navigation can hurt your ability to earn better search engine ranking.

Why?

It frustrates users and Google knows it.

There are literally hundreds of little, technical SEO features you should account for in your site. Applying these principles is not as much about organic search best practices as it is about user experience best practices.

All websites and web apps should apply these principles so they can deliver a good user experience that makes the application easy to use.

Work Toward a Repeatable/Testable System

Online marketers are obsessed with auditing their work. They review reports and data every day, often multiple times a day looking for and edge and places they can improve to get even the slightest improvement.

Developers at least like to think they do the same with automated unit and integration tests. But we all know how well that goes, me included.

We don't test enough. Nor do we automate these tests.

The good news is you can automate much of the tests required to make your software better.

The bad news is usability is still somewhat subjective and will require real human observation.

This does not mean you can automate much of your tests. In fact, I like to automate testing, even when it comes to SEO.

My testing is a combination of on page and technical SEO audit using Lighthouse, WebHint and some custom tests.

Lighthouse and WebHint do a great job of exercising your web pages against a set of simple and complex standards. I can't tell you how many tiny little details I have fleshed out over the past couple of years surfaced by these test runners.

The good news is they are nodejs based, open source and have command line interfaces (CLI).

This means you can automate them as part of your build and continuous integration processes!

What I have found problematic is the ability to run these tools inside AWS Lambdas, especially Lighthouse, because they tend to lean on running a headless browser. The problem is more a matter of lambda size constraints than technology. I expect this problem to be solved sooner, rather than later for me.

The cool thing about these test runners is they produce JSON and some other formats you can integrated into your build reports.

Lighthouse and WebHint both test for common technical features like PWA compatibility and page speed issues. Lighthouse has also added some simple SEO tests, but nothing as detailed as what I ultimately test for.

Lighthouse is used to power Google's new Web.dev and Page Speed tool. So you know it is important to the SEO crowd.

It is easy to configure these tools to audit your pages.

For Lighthouse you can use the command line like this to audit a live page:

Lighthouse From the Command Line
Lighthouse From the Command Line

For WebHint the process is very similar:

WebHint From the Command Line
WebHint From the Command Line

Wrapping it Up

Even if a developer is not involved with a consumer website where SEO is important, they should study search engine optimization, especially technical SEO because it will guide them toward creating better user experiences.

Better user experiences translate to happier customers with ultimately means more profit, even when the customers are internal employees.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel