DEV Community: Mariano Fernández Cocirio

Traffic light usability report —and how to communicate your test results

Mariano Fernández Cocirio — Thu, 25 Jul 2019 14:59:37 +0000

Sometimes when you are running some usability test is really hard to get quantitative results, and it's even harder to communicate those results in an effective way to other stakeholders. It's common that when you are running your first usability tests you just get qualitative data, and most of it is just from your analysis over participant behaviours, which is also valuable. But it's not always the most efficient way to communicate results to your coworkers.

That's why it's always useful to run your usability tests with a traffic light report close to you, but first of all, we need to know what a traffic light report is and how it'll help us to transfer information to the rest of the company.

Traffic light report

A traffic light report is a visual way to figure out where the users are struggling in our application. The most important information it gives us is how hard is a specific task for our users, and how hard to use is our application for each specific user.

The system is pretty simple, you write down some tasks you are expecting your user to perform, for example: pick a pair of shoes. Then you give those tasks to your users and check how easy it was for them to perform them.

If it was clear to them what to do you assign a Green value to that task. If the participant found some difficulties but was able to perform the task with minimal/no guidance then it's a Yellow. On the other hand, if he required assistance or it was really difficult for them, then it's a Red.

You can also add for example another metrics like time to perform the task. This metric might be helpful to set the value. For example, if you have run this task several times with different groups you might have a bunch of previous results, so you can assume that a specific task requires about 5 seconds, with this information if some user takes more than 10 seconds to perform it, even if he required no assistance, you might consider him into the Yellow group.

One example to understand it better

Let's say we have an online shopping application. This application has a complex signup funnel as it's trying to gather as much information as possible from the user to give specific recommendations once you signed up, and it also has a shopping tool inside where you pick a product and just buy it.

We'll create for our usability test three tasks:

Sign up
Pick an item
Checkout

Here is where you need to be smart as if you just pick small tasks as select a colour it might be too descriptive to the participant and give him an extra hint, also we don't want to overwhelm them by giving them a big amount of tasks to do.

In this case, for example, we'll divide the first task into four sub-tasks. We'll also divide the other two tasks into three and two sub-tasks. It's important to know how much is the granularity we want to achieve from this test.

In the following image, we can see the results of the usability test from five different participants, we have it structured in an easy to read way, and we also get the overall result for each participant and for each task. It's important to know that some tasks that are really difficult for some participants can result really easy for another participant. Here is when your persona analysis needs to shine like a sun.

From this test, we can easily get the critical tasks to improve are: Fill contact details, Add to cart, and Fill credit card details. As a common pattern, we can also see that we are struggling when the user is required to fill something, maybe it's time to rethink our forms.

These results are easily transferable to any stakeholder without any issue, as we can see the report is pretty simple and self-explanatory, you just look for the red sections to see where are the users struggling. It might be even better if we add the time to perform each task.

Conclusion

Sometimes we struggle to transfer results from usability tests. This is usually because we don't get quantitative results in a proper way and we rely on qualitative results from our observations.
But there are a lot of ways to get easy-to-read reports that can also add some quantitative information to our stakeholders.

Smoke test to prove your concept- researching before developing

Mariano Fernández Cocirio — Fri, 19 Jul 2019 13:15:04 +0000

Sometimes we found ourselves driven by the hype of a new feature or product. This might lead us to make decisions in a hurry, which usually is not a good thing, guts are good, but numbers and research are better. We've talked about some qualitative methods to evaluate some product fit, before by using personas.

But in some cases, just qualitative information is not enough and you will require quantitative data. There are plenty of ways and techniques to get quantitative data about a product or feature before releasing, in this article, we'll talk about a Smoke Test or fake landing pages.

What is a Smoke Test?

You create a new page that describes your new feature or product you are planning to build, and then you ask your visitors their level of interest by adding some call to action to buy/use, but instead of leading them into the product you display a "coming soon" page thanking the user for their time and asks for contact information to keep them in the releasing loop.

What's the main metric you'll get from this test? The conversion from a visitor to a user interested in your new product/feature. You can also measure the people leaving their contact details as highly intent people. But you should not centre just in them, even the curious people are people who will convert from visitor to lead.

You can also add multiple levels to your smoke test. But you should take in consideration that you'll add a frustration point at the end by not really offering the product, so you should keep it as simple as possible. Probably not more than 2 or 3 clicks before the "coming soon" page.

A new idea arrived at the company

To make it simple let's take the Shoes Selling App from this previous post. Someone arrived on Monday with a new idea, adding a subscription to receive new shoes periodically. This new feature might generate big income to the company but it also requires a lot of work from multiple departments to be realized.

After analyzing our personas and making some qualitative analysis it seems to fit into our current user-base. But to be sure we'd also like to have some quantitative analysis that validates the proposal, we want to reduce the risks of spending lot of time and effort developing as a company a new feature that doesn't really fit in the market.

Smoke Test time

To get the user intent we'll design a Smoke Test, this would consist of a simple landing page explaining the value proposition. Basically, it's a paid subscription to get new shoes every three months, the shoes will be chosen by our fashion specialists based on your previous orders and your profile so you don't need to care about buying new shoes.

Another important factor is: should we offer different plans? It means adding different categories as Basic, Plus, and Premium. Each category will have different prices which will affect the amount/kind of shoe you'll receive. All these things can be hard to decide just based on qualitative data.

Designing our Smoke Test

It's going to be a two layers test. First of all, we'll have a landing page explaining our new service, our main call to action is to subscribe to this service. From this first layer, we'll get the fit into our visitors based on interest, this is important as it can validate that the feature is a necessity in our visitors' life.

As a second layer, we'll add the different tiers. Here we want to know how much a user interested in this service is ready to spend, this might help our finance prediction to determine the profitability of the new feature. It might be a nice feature but maybe it's not worth it for our company offering this new feature.

Running our Smoke Test and getting results

Running it is the simplest part, you just need to use low resources to set these landing pages, some data tracking, and you'll get all you need to retrieve information to analyze.

After doing this you'll get your results, let's say that from every 2000 visitors we had 1000 clicks on the call to action from the first landing page, that means that 50% of our visitors showed interest in getting this new feature. After adding this information to your qualitative analysis you can make the decision of building this new feature…or not.

Final thoughts

It's important to validate features or products before investing time on developing them. Sometimes just a good idea is not enough, you need to validate your new features or products before spending a lot of time in development and releasing them.

Also, it's a good idea to add some quantitative data to your qualitative data, doing it you can decide easier if it's worth it to materialise the idea. You are also minimizing the risks to fail.

Why are personas so important in development?

Mariano Fernández Cocirio — Thu, 11 Jul 2019 13:00:19 +0000

What is a persona?

A persona is simply a fictional character created to represent a user type that might use your application. It should describe the goals, desires, and behaviour of a hypothesized group of users.

You usually build your personas using information you get from different user interviews and data you get from tracking in your application, is important that these persons should have a name, profession, age, etc..

Why you should consider them in your development process?

Sometimes you got an amazing idea as a Product Manager, or as a Developer. You pushed for it, you even sell it to the entire company, all the use case scenarios you can imagine are perfect. But after weeks of development and promoting to production you find out it doesn't match your users, they just ignore the feature, or even worst, they use it in a way the experience is awful.

The mistake here was that you were thinking the new feature without taking into consideration the actual users of the application, you were blinded by your use of the application, this is also a common practice in inexperienced professionals who can't distinguish between their usage of the app and the real usage.

Shoe app is back, now it's engagement time

Let's suppose that our online shoe shop from the previous post now wants to include a section where people can share their stories about how the shoes work for them. It seems to be a nice opportunity to engage the community and consolidate users to a long term relationship with the brand, this would also increase the trust leading to new customers.

Now the discussion is about how to add this feature, we can go into different paths. Do we want to go into a social media way with small stories? Do we prefer long articles in a detailed reviews way? How should the interaction with other users be? Maybe from some stakeholders standpoint, the detailed reviews are the best solution as it leads to better quality content, and it's easier to get organic traffic into it.

Time to ask our personas

When you don't know what your users will prefer, and you don't have the time or resources to run some user interviews or usability tests with multiple prototypes for a specific feature you can ask your personas. Developing personas is hard, at the beginning they will be really simple, but after a time each persona will get its own personality.

After reviewing our personas we might found out some interesting stuff, for example, we can suppose that the personas for our shoe app are mostly casual buyers who like to show their shoes but they don't really have the resources to go into a detailed review of each product.

Let say our most relevant personas are Ashley and Marcus. Ashley is going to share pictures of her new shoes using Instagram stories and Instagram posts, as she's a fashionista she has a lot of different shoes to combine outfits, her pictures will be full outfit pictures with shoes complementing them. Meanwhile, Marcus will share some pictures with his friends by Messenger after buying them, probably his pictures will be just the shoes, he won't even wear them for the picture.

This is leading us to a solution, we know that both ways of sharing are not oriented into details or reviewing the product, it's just to show other people they like how it looks because they are happy with it.

Making a decision

After reviewing our personas we can get that probably a solution thought for detailed reviews might not be the best solution. We need a solution focused on casual pictures with small texts. Probably connected with some social media, so we add this boost your profile with new traffic bonus to our users.

Most of the stories will be regular people, not shoe reviewers, which will hopefully push other users to post their new shoes too. By just looking at the personas and taking them into consideration at the time of deciding how the new feature is going to be implemented we can say we've dismissed the detailed review alternative, which was pushed by some stakeholders as a better solution.

Final thoughts

It's important to always think about our users, and focus the feature development on them, it doesn't matter if you have an amazing feature if no user is using it.
You should keep your personas updated and iterate over them regularly, they might even change as your application evolve, you should not sit in your first specification forever.

How to get information from your user minimizing the risk of losing them

Mariano Fernández Cocirio — Sat, 29 Jun 2019 10:58:43 +0000

Do you deserve my information?

Asking for information to our users is always hard. It’s usually one of the main concerns of every UX designer over there. If you ask for the email too early the user might leave the site as it’s not providing enough trust to give it their email. If you ask for it too late they may already get the whole value they were looking for.

Sometimes this information is crucial for your business. If your company catch most of the clients by email campaigns, you should optimize getting emails from visitors. Every visitor you don't get their email is a potential loss. It could even be a real loss if you are paying for leads.

That's why you should always ask yourself if the value you propose to your users is fair for the information you are asking for it. It's a subtle game of trust that has no real answer, you should adapt it to your needs and your users.

Some practical example

It's really important to find the right place where to add this new friction, let's say we are developing an online car selling application. Your application allows users to:

Pick a car: Select a car by model, colour, age of manufacturing, etc.. Read details about the car: Specific information about the car itself.
Check availability in their area: Sellers in your area offering the car they want.
Buy the car: End the transaction by filling your personal information and finally buying the car.

Everything is about timing

First of all, we need to detect where we are getting the biggest drop, it's probably between checking availability in their area, and buying the car, which makes sense. At this point, we are letting all those users leave without asking anything about them, there's no possibility to re-engage them by marketing campaigns, nothing.

That's why we are going to make mandatory filling your email at some point of the flow. Now the question is: where should we add this friction? As we discussed earlier, if we do it too early we might lose most of the traffic.

Now it's time to think about what differentiates your product adding the biggest value, in this case, it's pretty visible that checking availability near you is a pretty big value, saying this we are going to ask for the email in exchange for showing availability in their area.

This way we also allow users with low intent to interact with our page building trust by reading details about cars, so when they are ready to make the next step they can do it. Every user is getting value from your applications, it's important to not exclude lower intent.

Iterate the way you ask for information

We'll ask for the information inside a modal, but there are different ways to do it, let's first see a pretty simple way of asking for the email in a basic modal.

This first iteration is lacking some important stuff, it's not clarifying what the user is gaining by giving you their email. Why would someone give you information for
free? It's important that you explain the value for giving their email. In this case, they'll be able to check sellers in their area and finally buy the car.

As a last minor change, we can improve a little bit that call to action, continue doesn't catch your eye really, we can also add some hierarchy to the continue and the back buttons, making it catchier to press continue. These are small changes that might help to get the user attention wherever you want it to be.

Now our modal is adding value to our user and making it clear what to do. You should also add some legal stuff about they accepting your policies, or make it clear you are GDPR compliant if you are in the UE.

Some extra tips

Make the input field easier for the user, for example, if it's an email make sure you add the type to the input. These improvements affect a lot the user experience.
Play it smart, most of the time when users see these dialogues they just try to avoid them, so you need to be smart, an easy thing to do is for example not disable the main call to action but once they click it if they didn't add their email just autofocus into the input and add some small message/display error to make it clear that's mandatory to continue.

Conclusion

Asking for information is not easy, you'll have a big drop off rate, but sometimes it's better to filter your users to a certain point. But most importantly, you should never forget about making it clear to the final user what they'll win by trusting you.

Build your own Babel-Plugin from scratch

Mariano Fernández Cocirio — Fri, 21 Jun 2019 10:12:06 +0000

A brief introduction

First of all, let's talk about Babel, Babel is a transpiler which converts code from JavaScript to JavaScript, maybe you are a little bit confused, but let's take the classic JSX example. When you code a React application you are not writing standard JS, and Babel is the one who translates all that beautiful code into some JS that your browser can understand.

How a transpiler works

Well, all of this is pretty cool, now it's time to talk about how does it works, it's really simple, to be honest, it's just a visitor pattern which is applied in every AST (AST is the Abstract Syntax Tree generated after processing your input code) node. This pattern allows us to effectuate some actions like modify this AST before generating the new code.

A classic visitor pattern

A simple example

Nowadays is really common to hear about CSS-in-JS tools, like Styled-Components, or Styled-JSX. So let's create a simple CSS extractor, as requirements we are gonna make the assumption that all the styles must be declared in a function called componentStyle if we are talking about a non-stateless component.
The way we are gonna implement it is by creating custom JSX-tags that are gonna be listed as variables inside this function and associated to an object containing the desired style, here we have a simple example of a component defining the tags and their associated styles, as convention to make it easier the tags are going to be called STYLED_<HTML tag>.

Now that we have decided our example to follow we need to make it works as expected, our goal is to:

Extract CSS from JS
Generate CSS files
Replace tags from JS to standard tags and associate them to CSS styles

First of all let's define our visitor function, as a plugin we are required to exports default a function that returns an object with the field visitor in which we have defined the callbacks associated to each AST node we want to modify or to effectuate any action on it. In the next code, we can appreciate the visitor that we are going to apply and a little description of what are we going to do in each case.

I'm not going to write all the logic needed in each case because it's really simple, you can check the final work HERE. But basically that's how we create a new plugin that extracts the CSS from JS, and allows us to use custom tags, I've also added in that repo an implementation to stateless components where you take the styles from the parameters when you call the function, so there is another hook on the visitor over the CallExpression node.

Now you just need to hook it as any other plugin on your .babelrc and you will be processing your code with your own plugin, allowing you to create new syntax and to create a whole new world, or a whole new set of problems, haha.

Conclusions

You don't need to be an expert to create a new Babel plugin and make your own syntax extension.
Things are not so magical as they seem to be, is important to know how Babel, Webpack, and other tools work. A funny way to do it is by creating a plugin for example.

Unsolving the mysteries of yarn/npm link for libraries development

Mariano Fernández Cocirio — Wed, 19 Jun 2019 09:37:48 +0000

Introduction

Imagine you are developing a web app, that web app belongs to a family of web apps who shares the same style in their visual components, which means that you are probably going to build a UI library to centralize all your components. That will give you the possibility of changing some behaviour, even look and feel of specific components across all your applications by just modifying that library.

Now we have an issue: How do we test our library integration with the rest of the ecosystem locally without releasing a version every time we modify something? That’s a common bad practice that you’ll see at some companies, just releasing beta/minor versions to test stuff as they don’t have a local way to test the integration of the library with their apps.

Testing the individual components from your library can easily be done by using for example Storybook, but the integration with the rest of your applications is the tricky part, here is where you should use yarn link, the idea behind this is pretty simple: It just creates a symlink to whatever you point to.

Time to add some real work

Let assume we have the app myApp who uses myLibrary-UI, being myLibrary-UI the UI library that provides all the base component to myApp. You are gonna have something like this in your package.json:

Right now when we run yarn we can say that it generates the following structure: myAppis going to contain our library in its package, but if we want to use the local version instead of the published version, how do we override the version it uses?

Our app containing our library

It’s pretty simple, you should just build your library locally, then you run yarn link in the directory you build it, by doing it you’ll register your package locally. After this, you should just go to the root directory of your application and run yarn link "@yourCompany/myLibrary-ui", this will create a symlink to your local copy that will be resolved before the copy installed by yarn.

WARNING: if you run yarn again, this link might disappear, you’ll need to run the last command again.

Our app linked to our local version of the library

By now we already have our app running using our local version of the library, this way we can easily test the integration of the new version with our app, and we can also use it to prepare our app to adopt any breaking changes from our library in case we need a simultaneous release. This might seems to be pretty straight forward but now is when the real issues begin.

Multiple definitions

I’ll assume we are using React in our library, but we are also using React in our application, this should be easily solved by our package manager while installing them in a regular way.

React is just installed at the top level, then used by children

But as we are linking it locally we have the problem of multiple React definitions in our project, this gonna generate multiple errors that are not that easy to debug and really not very descriptives, like for example:

Unhandled Rejection (Invariant Violation): Invalid hook call. Hooks can only be called inside of the body of a function component.

React is defined two times causing errors

The easy way to fix it is by using the link command, we just go to our library and we create a link from there the React definition in our application, something like this: npm link "../myApp/node_modules/React”. This will create a symlink in our library to the React definition in our app. The result is our project will only use the React definition in myApp but it will run our local version of myLibrary-UI.

Now we are using just the main definition

Now you are able to develop your library and test its integration with your apps locally just by using link commands. There are other ways to avoid multiple definitions, for example, let’s say we are using styled-components in both packages, but our app is also using NextJS, we can solve this issue by adding the resolver for this specific package in Webpack configuration:

Conclusion

Sometimes it’s really important to test your library locally so you can test its integration with other apps that use it. That’s really tricky sometimes but it helps you a lot to develop a better library.

By using link command you can easily achieve a configuration that allows you to test your libraries in a local environment, saving you from making for example test releases to check the integration.

Hope you like this article and most important I wish you find it helpful, I’ve been fighting with issues to test integrations between multiple packages a couple of times, some of this came out after several fails by myself.

The importance of the empty state in your application

Mariano Fernández Cocirio — Wed, 19 Jun 2019 09:06:36 +0000

Today we’ll be selling shoes

Let’s say we are developing an application, that application main purpose is to sell shoes, that online selling tool has two main selections by the user:

Look for your desired shoe: The user has the ability to write in a search bar the shoes’ brand.
Select a color for your product: After selecting a specific pair of shoes the user must choose the color he prefers.
It’s a pretty simple application but we’ll see how it can be iteratively improved by being conscious of the empty states we might generate.

Perfect flow

In a perfect situation, our user’s going to input his preferred brand, after that he’ll visualize a couple of shoes. He’ll choose the one he likes, and then he’ll pick a color before proceeding to a success screen.

Wireframe for perfect flow

But there’s something we are not taking into consideration: what should happen if there are no results in the initial search? And what about if there is no stock for the particular shoe/color combination our user had chosen.

Not everything is perfect

As a first solution we might be tempted to decide not showing any result on our first screen if we don’t match any product to our user’s query to solve the first issue. Meanwhile, the second one is really problematic, because at this point the user has made two choices and we need to tell him there is no stock.

Wireframe first solution

Now we are getting into the real problem, the empty state, this is a very poor way of managing an empty state, on the selector screen the user has no feedback, which is really bad, as the user can be confused, not knowing if he needs to wait for something, or he might be even thinking the app crashed. In the second screen we tell our user which is the issue, but he is going to be facing that feeling of: "everything I did is lost". But more important, in both screens, there is no clear next action other than close the application.

Guiding through emptiness

It's time to make this empty states gorgeous. As a first iteration we need to add some clear feedback for the user, it's important in this cases that the user knows what's going on, and more important is that he needs to understand our application is not useless, and he can keep using it.

Wireframe adding some actions in the empty state

To start with, we can add visual feedback to our chooser, making it clear for the user what had just happened, in addition to this we should also explain to the user how to continue. In this particular case as the search bar is still being displayed on the same screen we can simply tell them to use it.

But that's not the case in the success screen, as all our choices disappeared from our screen, in this case, we can be more aggressive and add a button to go back to the previous stage, this way the user won't feel all his progress is lost. He's still two clicks away of getting his shoes.

Both of these solutions have something in common, we are "undoing" the last step and requiring the user to re-do it, but sometimes we can guide forward from the emptiness itself.

Guiding to a brighter next step

Sometimes we can save time for our users, and also get closer to a conversion simply by showing them a different choice that will guide them to the next step. This way they don't need to re-do the previous step every time they choose an option that might guide to an empty state, we are also giving them the security that this choice will result in the desired outcome for them.

Wireframe adding recommendations

In our app the effectiveness of the first screen will depend on how good is our system to recommend similar shoes. If we can get a good recommendation we are potentially not losing a user. In the second screen, it's more about showing quick buys for the product they've already chosen, at the end of the day both additions are trying to allow the user go one step forward without the friction of re-doing a step.

Conclusions

Empty states are important, you might be losing customers just because your empty state is a dead-end with no action/explanation about how to continue. We should not forget that frustration is a common dropoff reason, and what's more depressing than not knowing how to continue?