eCommerce - Naguel

#eCommerce

Do not forget about the emotions while selling something

23 August, 2017

3 min read

Do not forget about the emotions while selling something

I'm selling two newest iPhone, Space Gray color, both with 256 GB of capacity. When I bought them I wasn't sure about getting the 64 GB version or the bigger one, but I made up my mind in favor of the 256 GB version and I'll tell you why it was a great decision.

Last year I went on a family trip with my mom and sister to a Brazilian beach where cellular signal wasn't available all the time, meaning LTE was a luxury, and also finding WiFi was a Tom Cruise's "Mission Impossible" remake possible plot.

In this scenario, the idea of today's about everything being in the cloud and not in the physical devices was a no go for me.

The trip was beyond great. I spent a lot of time in the water with my sister trying to record the best slow motion videos: sometimes trying with just the water, sometimes filming the sand to see if that improves the video, then letting my sister try some tricks in front of the iPhone camera over and over again until we get something good.

At the end of the day we ended up with many many GB of videos, and a job not done yet. Before dinner, all nights, and most of the times waiting for our mom to get ready, we selected the best shots in order to create a video, cinematic music included, to show to mom as if we were two Directors showing the final cut of a Hollywood movie to a film criticism.

The other phone, while exactly the same, it was just used for some work stuff. It's a great device for reading emails, writing emails, and taking notes.

The difference lies in the emotions

While both are the same technical speaking, they are not the same emotionally speaking. If I still need to prove my point I'll will continue telling you fake stories including a beach, a mom and a sister until your eyes get wet and you rip this phone out of my hand while letting me keep the one used for work... because that's the whole point.

I know it's very obvious I'm appealing to your emotions in the last story, but the true is that we're all victims of this trick in a regular basis.

Think about it. Think about the last time you bough something on Amazon, eBay or Mercado Libre, when you searched for a product you already knew, ended up with three or four browser tabs with similar publications of the same product, different price within a short range, and then you made a decision from where to buy based on not much logical data but confidence on the seller, the aspect of the website, the fact that one had a better description with a video of real people using the product, the fact that one had reviews from previous buyers.

Think in Coke showing a couple jumping of a cliff into a lake, McDonald's showing a single mom with his kid laughing while eating fries, a perfume showing a good looking guy with three Victoria's Secret angels.

I remember a local ad I often see on TV showing a divided screen where on the left you can see a cute lady getting ready to go out on a sunny day, and on the other side a big man wearing a hood and preparing his tools to break into the house of this lady the moment she step out. There you have the victim, the villain, the conflict... and the hero? A trustworthy armored door at an accessible price.

And Apple?, oh, boy, those guys really know everything about selling feelings instead of products. I remember during an Apple's Keynote somebody, probably Tim Cook, introduced "Live Photos" (you know, that feature that records a few seconds before and after an static photo) and said something like "This feature allows you to see a photo, gently press on the screen, and get a sneak peak of what was going on during the shot of that static image".

A time machine that shows you 3 seconds of video and audio around the static shot. Right in the feels.

What you're selling is a hero

Your product, service, software... whatever is the thing you're selling, it can be the hero of a story. A story where there's a problem your potential customer has.

The problem is the villain in the story you need to start telling. It can be pretty obvious like in the ad for the armored door, or very subtle like in the McDonald's ad where they tell that they know how hard it is to being a single mom but still you can come upon great moments with your son in their stores.

Spot the villain, disclose the problematic, then introduce the hero to your customer so they lived happily ever after.

eCommerce Sales

How a VTEX developer looks like from a technical point of view

09 May, 2017

3 min read

How a VTEX developer looks like from a technical point of view

If you happen to be on a similar position as I am where one of my task is to conduct interviews and vote on someone getting hire or not, you also have to be able to establish if that person can work with a specific platform.

It is not the same working on a VTEX store, an ORO implementation, or in a Magento project. For each platform you have to have a specific set of skills, and again, depending on the platform, more experience on some specific skills are necessary and the seniority on a specific ability vary when you change the CMS you are messing with.

VTEX requires a front end developer with a signed certification from his mother saying that he's great with those "Find the n differences" puzzles you get on the Sunday's newspaper, because the primary task he'll face is to transform a given design into "code", as pixel perfect as it can be.

So, how it looks like now?

Translated to actual skills, for a start it means we're looking for someone very good at xHTML, CSS (and/or any CSS preprocessor like SASS or LESS), that can also handle simple JavaScript logic or jQuery for basic UX interactions.

Bear with me if you not agree on that "simple JavaScript logic" statement, because there's a reason why I said "for a start". With this specific developer you are kicking off the team you need for a VTEX implementation but you are not finish yet.

Based on my experience, someone with the ability to handle the layout will cover a high percentage of what the project needs. Seriously, even on highly custom VTEX projects always the largest amount of workload falls on the person who handles the implementation of the designs and that's why is very important to have someone who nails this task.

The next step is to choose between two options: we either look harder for a person with the mentioned skills that can also handle the logical part of a development, or we get another team member for this job only.

If we go for the first option, now finding the developer became a little bit more complicating.

I think that considering a lot of front end developers, on one end we have the "developer who handles the layout and leaves the logic to back end" and in the other side the "kind of full stack developer hungry for programming but with no love for the look and feel".

Our first option requires us to find someone in between, and that's hard (talking, again, from my work experience). Personally I'll go for this option, because, personally, I feel more comfortable with those "in between" developers. But that's just me.

The second option is more suitable when looking at this from a company level where you have multiple VTEX implementations.

Imagine an scenario where you have three VTEX projects ongoing, each with a person assigned full time implementing the layout only, and a fourth developer jumping from VTEX 1, to VTEX 2 and VTEX 3 working on the customizations only, while leaving the "make this as the designs indicate" to the full time assigned coworker.

The person in this second option needs to know JavaScript for real, because all VTEX front end custom stuff always falls on the need of use of JavaScript.

The developer, sort of acting as a back end developer in this platform (in a manner of speaking) will be dealing with the logical part of the implementation like struggling with the APIs and integrating with VTEX's Master Data.

But how it will look like in the future?

The platform is evolving constantly and it is on its peak on what updating the technology stack refers. This means that what I just said above still applies, but we need to consider what is coming.

In the not so distant future the idea of VTEX IO as the VTEX's web application development platform is that custom (and useful) customization that takes places on a specific VTEX store become an App, in a sort of plug and play plugin for that specific store and others.

For example, let's say you have to development something to get the users' email using a form in order to subscribe them to the newsletter configured using MailChimp. Do it once, make it an App, and reuse it on the future or sell it to other existing stores seeking for the same functionality.

In this new world, besides the fact that you need a little bit of npm and the use of a Terminal to set up your workspace, you'll definitely need to know React and GraphQL in order to build the application.

So don't get sleepy.

VTEX VTEX IO Front End Web development eCommerce

Understanding the product's name front end logic in VTEX

21 March, 2017

2 min read

Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the Product in the Admin? Or is it showing the name we entered in the SKU? Or is it showing both?... or why sometimes it seems like VTEX is using the Product name and in other occasions it is using the SKU name?

In other words, what's the name I'm going to see in the front end of my VTEX store when creating a new product?

I'm writing this down because I found there's always a confusion about what is VTEX showing as a name for a product when looking at it in the front end (like in a category or product's page) considering there's a tricky logic there that involves the Product entity and the SKU.

Product entity name and SKU name?

To avoid any misunderstanding, let's discuss first what I mean by "Product entity name" and what I'm talking about when referring to the "SKU name".

When I say "product's name" we all think about a product as a whole, the item itself and the name that item has. But a product in VTEX is divided into two thing: The Product (or the Product entity) and the SKUs included on that Product.

I know I might sound philosophical and delusional but just take a look at this screenshot so I explain myself better.

understanding-the-products-name-front-end-logic-in-vtex-01-1

Is our site showing the name from the first column or from the second one?

Which one is going to appear on the front end of the VTEX store?

It just depends on this simple logic you need to consider.

If the Product entity name is exactly the same as the SKU name, then VTEX will show only one. Take a look at the screenshot above where the names in both columns are identical, meaning the front end will only show "iPhone X 64GB Silver".

On the other hand, if the name in the Product is different from the name in the SKU, then VTEX will show the two names separated by a dash (-).

For example, if for the Product we have "iPhone X 64GB" and for the SKU we have just "Silver", then the result on the front end it is going to be "iPhone X 64GB - Silver". That simple.

understanding-the-products-name-front-end-logic-in-vtex-02

Knowing that, if you're facing the "problem" in VTEX with the front end showing the names "duplicated" or if you didn't understand from where that final name is coming... now you know.

Keeping both the Product and SKU with the exacly same text (not even a difference in the capital letters) will show only one name, no dash.

VTEX Web development eCommerce