“I survived Gutenberg” series – Chapter 1: Rejection

It’s been almost a year and a half since the new WordPress editor “Gutenberg” was released officially as the default WordPress editor. However, before this release, we had the option to install Gutenberg as a plugin so we could test it and start getting familiar with it.

As any new major release, it introduced some challenges to WordPress editors and developers (mainly developers), besides some bugs and usability issues.

Unfortunately, it was not well received by some developers (myself included) who preferred to continue working with the Classic Editor, so a new plugin started catching on: The Classic Editor plugin, which at the time of writing this post, has more than 5 million of active installations. Fair enough for all those websites which were already using the good old Classic Editor. The Classic Editor plugin became a lifesaver for those websites.

By the way, this plugin is an official WordPress plugin, so it was released by the WordPress team precisely to avoid breaking those websites’ content with the new Gutenberg functionalities. They also announced:

This plugin will be fully supported and maintained until at least 2022, or as long as is necessary.

Once again, fair enough for all those sites using the Classic Editor, but what will happen after that date? What if the plugin developers decide to stop offering support to this plugin? Well, then it will be time to move away from the “good old times” and welcome the present.

Going back to “the rejection stage”, and talking about myself, I didn’t want to switch immediately to Gutenberg as soon as it was released, not for being afraid of change (well, actually I was afraid of that huge change)… anyway, I was aware there were many latent bugs and compatibility issues at the time it was released. In my opinion, the release of Gutenberg was too premature, I would have wait a bit for it to be more mature, more robust, and with fewer bugs.

Some of the most notorious issues when it was released were its lack of accessibility support, performance issues, some editor UX issues, lack of support on other plugins (like WooCommerce), etc.

In fact, Matt Mullenweg (who was leading the release process), in his presentation during the WordCamp US right after the launch of Gutenberg, did acknowledge that mistakes were made during the launch, and that he had learned the lesson so that these mistakes will hopefully not be repeated.

I heard (and read) many people saying that Gutenberg was a bad move and that it should never have been integrated to WordPress core as its default editor. But I think some of these feelings were also encouraged by personal reasons: fear of change, having to change the way to build custom themes, what would happen to the custom fields, the need to learn ReactJS to be able to build custom blocks, some people (like me) had already a defined workflow to build entire sites with Advanced Custom Fields and to offer a great edition experience with reusable fields, repeater fields, flexible content fields, etc. “Now, with Guteneberg, we’ll have to change everything we’ve built during these last years”, we said.

I know many people was really excited about Gutenberg, I actually was, but at the same time I felt worried about starting using it on my new projects, and more than excitement, the Gutenberg release caused anxiety and uncertainty to some (or most) of us. Instead of an improvement, I felt it would introduce a risk to my new projects, I really felt it like an Alpha release instead of a Production release.

And there are tons of additional reasons why many people felt this way and this is why I called this first chapter “Rejection”.

But what’s next? Sometimes after a rejection comes a less rejective or acceptance stage, but, do you think this was the case of my experience with Gutenberg? Judging by the title of this post, we could say yes, however accepting something not always means embracing it or adapting to it. If you want to know what happened after this rejection stage, and if I embraced it or just kept doing my job with my good old structured way to build websites, then be in the loop and wait for my next article: Chapter 2!

Growth-Driven Design & User Research

Doing user research to improve the user experience is an important piece in the process of designing any digital product, collecting information from users to better understand them is essential to launch a successful product.

However, as designers when we work in a team that follows an agile process many times we find several challenges and we ask ourselves:

Where does the UX Research fit in?
What can we do without hindering agility within our team?

Unfortunately, there is no simple answer for these questions, everyone has to find out what is the best way to work in their work environment, however, this article is an attempt to show only one of the many ways to do User Research within an agile process, I hope it will serve you as a baseline so you can start implementing a process that works for you.

The Growth-Driven Design process

First of all, it is important to explain the process that we will use as a guideline, GDD or Growth-Driven Design is a process that is used on top of the agile methodology, broadly speaking GDD is based on 3 fundamental phases:

The 3 pillars on which the growth-driven design process is based


The strategic phase is important to form a clear understanding of users and business goals so we can build the digital product around those two important aspects. As a result of the strategic stage, we define objectives, Jobs to be done, User Personas, Fundamental Assumptions, User Journey Mapping, and Information Architecture.


At this phase, depending on the type of project, we will build and launch the product to the market, which will serve as a starting point to later build on it, by launching a product in an agile way we can begin to obtain feedback from users quickly to make better decisions and improve the product based on the user’s real needs.

Continuous improvements

The objective of this stage is to dedicate time to the growth of the product to offer greater value to the user, help to scale, and contribute to the growth of the business. It is at this stage where the team collects information from real users to build a list of actions to take that improve the user experience.

How to do UX Research within the GDD process

Now that we know the process to follow, we can go into more detail and indicate when and how user research is done within this process.

Before that, I think is important to explain that we will split User research into two types:

  1. Strategic Research
  2. Tactical Research

Strategic Research

It is the research that is done with the objective of having a complete understanding of the users and the business goals to have a solid base on which to make the strategic decisions of the product, this type of research is less frequent and is carried out outside of the Sprints.

The duration of the strategic research is more than a week since you have to talk continuously with users and stakeholders to get the information we need to help us create a product of greater value for both of them, and as a result of extensive research, we will have results that could last between 3, 6 or 12 months.

As a result of this type of research, these types of documents can be created:

  • User Personas
  • Journey maps
  • Empathy maps
  • Affinity Diagrams
  • JTBD

Tactical Research

It is the research that is done to identify usability problems and answers specific questions of the product that is being built and serves to validate specific hypotheses, this type of research is frequent and is carried out within the Sprint by the product team.

To carry out this type of research you can run different tests like the following:

  • Usability Test
  • A/B Testing
  • 5-second Test
  • First Click Test

Tactical Research Example:

“The text of the button should say “Send” or “Register and continue”? The answer should be given by an A / B Testing study that indicates the correct direction to follow.

Strategic Research Example:

“Who are our users? What are their goals? How does our product fit into their life? How does our product solve their problems?” The answer should be to make user interviews and try to get to know our users better to make decisions about our product that improve the way we solve our clients’ problems.

Now that we know more details about the two types of research that we can implement, we will put them in context, below we can see a graph that shows at what specific moment in the Growth-Driven Design process we can do each of these types of research:

User research within the Growth-Driven Design process

As we can see in the image the strategic research is done at the beginning of the project to help with the product strategy and then, once the product is launched within the continuous improvement stage we must do short and constant research that will help us take specific decisions when building new features.

It is worth mentioning that the strategic research is done at the beginning of the project and also must be carried out every 3 months to review the strategy and ensure that the needs of our users remain the same, this way we will update our strategy and we can continue with the tactical research based on the updated strategy.


In summary, the research on user experience cannot be restricted by trying to be more agile and move faster in the development of a product but it cannot be unlimited in time.

It may be tempting to want to do as much research as possible at the beginning to have as many answers and information before start developing the product but the truth is, we will never have all the answers and what might realize is that the more we learn the more we need to know, this is not productive either, the ideal scenario is in the balance between the two things, do strategic research first to have a well-founded strategy and then launch the product to learn from real users that help us improve the product in a more efficient way.

How to measure and monitor site performance with Google’s Core Web Vitals

On may 5th, 2020 Google announced Web Vitals coined as “Essential metrics for a healthy site”. It’s evident that performance has a direct impact for businesses and this initiative from Google reinforces that. Being that our mission is to co-create high-quality software with our clients we definitely correlate performance with high-quality.

Why does it matter?

Performance is about human experience. It’s about how people experience the web. For the vast majority of people web is a key touchpoint their life. Performance can both positively or negatively impact how people feel. To illustrate why performance matters, I’ve pulled some data from the web to show both the positive and negative impact of performance.


higher conversion on sites that loaded in 2s or less


BBC lost 10% of users for every additional second of load time


of consumers expect a web page to load in 2 seconds or less


Pinterest’s increase in traffic and sign-ups when wait times reduced by 40%

User Centric Performance Metrics

Given performance is about people, we need a method to test performance based on peoples perception. The only way to truly know how your site performs for your users is to actually measure its performance as those users are loading and interacting with it. This type of measurment is known as RUM (Real User Management).

Noting that a single metric exists that can measure a sites performance based on a users perception there are several types of metrics:

  • Perceived load speed – how quickly a page can load and render all of the visual elements to the screen.
  • Load responsiveness – how quickly a page can load and execute any required code in order for it to respond quickly to a user
  • Runtime responsiveness – once a page is loaded, how quickly can the page respond to user interaction.
  • Visual stability – do elements on the page shift in ways that users don’t expect and potentially interfere with their interactions?
  • Smoothness – do transitions and animations render at a consistent frame rate and flow fluidly from one state to the next?

Metrics To Measure

Based on Google’s announcement of Web Vitals the following metrics are a set that they deep as most necessary when measuring user centric performance. Google has mentioned that these metrics will evolve over time.

LCP: Largest Contentful Paint (loading)
FID: First Input Delay (interactivity)
CLS: Cumulative Layout Shift (visual stability)

Definition & Target Speed

  • Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
  • First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.
  • Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

Field & Lab Measurement Methods

There are many instances where measuring performance from an actual user is not possible such as when a site is in testing or before moving into production. Given this fact, two methods for measurement have been established:

  • Lab – Before production, pre-release, local testing, etc
  • Field – Real User Monitoring, based on how the actual user experiences the performance

Toold for Field Measurement:

  • Page Speed Insights
  • Chrome UX Report
  • Search Console
  • Firebase Performance Monitoring

Tools for Lab Measurement:

  • Lighthouse
  • Chrome Dev Tools

Simply Measure Your Sites Performance

The simplest way to get started in measuring your sites performance is to use the Chrome User Experience Report in Google Data Studio. This report indexes all websites across the web into a BigQuery database which is publicly available online.

Setting up your dashboard:

  1. Go to Chrome UX Dash – the connector for the Google Data Studio Dashboard.
  2. Input your sites domain in the origin URL field
  3. Click next
  4. Choose create report

Chrome UX Dashboard for WeAreNolte.com

A talk I did during Nolte’s weekly Lightning talks on this topic.

Source: Think With Google, Google Developers:Why Performance Matters