Shopify Expert Insights

E-Com Advice from our experienced in-house team

People don't buy features, they buy benefits.

Product pages often highlight just features but that's not what sells products. Benefits appeal more directly a reader's emotions. It's especially true if that benefit is solving a problem.

Let's look at how Apple sells the A6 chip in the iPhone:

Instead of leading with an explanation of the high zoot architecture of the A6 chip, they sell the key benefit of "Long battery life." No one really cares how the A6 chip is made, but everyone can relate to the pain of a short battery life.

I find the best way to translate features into benefits is to think of what problem or pain they solve for the reader. If I was shopping for a new car, and I was worried about the price of gasoline, then I'd look for cars with good milage. I then might buy a Prius because it gets 46mpg (the benefit) but not necessarily because I want a hybrid. Hybrid drivetrains are a feature, good gas milage is the benefit. As a fuel-economy conscious consumer, I really don't care too much about how the manufacturer achieves great milage, I'm only interested that it's fuel efficient.

Are you selling features or benefits? How are you solving your consumer's pain?

Running AdSense on a responsive site doesn't have to be hard.

To promote a clean user experience, Google allows modification of the AdWords code (so long as it doesn't artificially inflate clicks or otherwise hurt the advertiser.) In the past, the only way to deal with responsive ads was to hide them in different layouts. If you have a simple single column website (like CalmingManatee) you can use the some simple in-line javascript to swap in the right format ad based on the site's width. In your AdSense dashboard, create one of each ad type, and drop in your publisher and ad IDs. It's pretty straightforward.

<script type="text/javascript"> 
adUnit   = document.getElementById("google-ads-1");
adWidth  = adUnit.offsetWidth;
google_ad_client = "YOUR_PUBLISHER_ID";
if ( adWidth >= 728 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width	= 728;
  google_ad_height 	= 90;
} else if ( adWidth >= 468 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 468;
  google_ad_height 	= 60;
} else if ( adWidth >= 336 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 336;
  google_ad_height 	= 280;
} else if ( adWidth >= 300 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 300;
  google_ad_height 	= 250;
} else if ( adWidth >= 250 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 250;
  google_ad_height 	= 250;
} else {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 200;
  google_ad_height 	= 90;
} 
</script> 
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

Not all browsers are made equal.


Chrome, Firefox, and Safari showing differences in font rendering.

A website is just a set of instructions describing how a site should look. It's up to the browser to render it, and every browser renders things a little differently. For example, a common problem we've run in to is that Chrome and Firefox round percentages differently which can cause responsive layouts to break at different resolutions.

When someone finds an inconsistency, we ask them to give us the details of their environment and provide a screenshot (if possible) of the issue. Providing technical details doesn't have to be intimidating, we use Support Details to quickly and accurately get a clear picture of their environment. Once we have that, we can attempt to recreate the issue and address it.

No one wants to "submit" to you.

The default label for a button on a form is, and always has been, "Submit." That's a terrible label.

Submit doesn't provide me any context beyond the obvious: my information will be delivered somewhere, probably to someone. Even worse is the meaning of the word submit. It literally means "to give over or yield to the power or authority of another." Unless our form is for a rehab program, our user probably doesn't want to submit to anything.

Let's consider our newsletter. To sign up, you provide your email address and click a button. Since a button provides an action, it would make sense to use a verb. "Subscribe" would work. Subscribing is what we're directly doing. That's called a task-based label. It describes what we're doing, not why we're doing it.

To reinforce why we're subscribing, I could use a benefits-based label. Since I want you to sign up for this newsletter to improve your website, I could use "Improve My Website" as a button label. The label describes the benefit provided by clicking it, instead of the literal action. This might improve conversions. Benefits-based labels are uniquely suited to conversion forms because they remind the user why they're signing up.

A benefit based label isn't always appropriate. Consider the button to to post a comment on a photo. For that, we should just stick to the task. "Post Comment" would be best. Task-based labels are always better than "Submit," but benefits-based labels may increase conversions. The only thing left to do is split-test it and see.

You have a great idea for a smartphone app. What is the process of putting it together? How tech savvy do you have to be? And then what is the process to get the app into an app store?

Aside from client work, we've got several successful websites we've built independently. One of them, and my favorite, is Rainy Cafe. Lifehacker described it as, "a simple little site that plays both the bustle of a coffee shop and the soothing sound of gradually increasing rainfall." It's essentially a white noise generator. The site gets around 100K visitors per month. We decided it would be the perfect site to translate in to an iOS app.


Rainy Cafe: Ambient Noise to Soothe and Boost Productivity

We applied for a developer account with Apple. To prove the legitimacy of a business, Apple requires a Dunn & Bradstreet number. This was our first stumbling block. It takes weeks to be verified by Dunn & Bradstreet, and strangely, it takes weeks for Dunn & Bradstreet to update their database with Apple. Just getting our developer account took over a month because of that. During that time, we put the app together. We used PhoneGap to translate our existing web assets in to an iPhone app. It was remarkably simple, within an hour we had a working app. That's spectacular since we previously had no iOS development experience. Adding native features like background audio support wasn't difficult either. PhoneGap community's support is excellent. Any question we had during development was just a Google search away.

Once we had the app built, we needed to test it. While we knew the app worked in Apple's software simulator, we wanted to be certain it worked in the real world. That's where having an approved Apple developer account becomes a necessity. To load an app on to an actual iOS device, the device must first be "provisioned" by Apple. It's a straight forward process of getting the device recognized by Apple, "code signing" the test app, and then launching the app on your own device. It's necessary, not just important, to test on real devices. The iOS simulator is great but imperfect. We have noticed some idiosyncrasies between the two environments.

Since our app was simple, we didn't have any snags when testing, and we're ready to submit our app for review by Apple. It took five days for them to our review app... and reject it. They found that our Rainy Cafe app provides "a very limited amount of content and a very limited set of features" specifically because it "only contains two ambient noises."

Since our app had exactly the right amount of features to accomplish its goal, we opted to suspend development on the iOS app. When we can think of new features that make sense, then we'll resume development. Even if we did, it would still be a gamble. What if we add a sleep timer? Or a new selection of sounds? Would those things really add to the user experience? Would Apple approve the app then? Ultimately, Apple is the gatekeeper to an app's success, which makes building an app a gamble.

It can be tough, frustrating, and even painful to get approval for a design from a client.

Anyone can offer an opinion on design, so they do. Worse yet, these opinions are based on an individual's own subjective taste, not a professional designer's years of objective experience in solving complex problems. Instead of butting heads with the client, try some of the strategies we use at Ethercycle to work collaboratively with our clients.

Become the Expert

I always backup my reasoning with multiple articles explaining why something may not be a good idea, and then offer an alternative.

For example, if a client wanted to include background music on a brochure site, I would write to them,

It's not in your best interest to include audio on the website, users find it a turn-off.

Here are some articles on the subject:
  1. Regrettable User Experience: website background music
  2. Stack Overflow: Web Usability - Background Music
Including a video, if you have one, is a better way to engage users with both sound and audio.

It's easy to say that the designer is wrong, but it's hard to say the design community is wrong. No one likes being wrong, so it's important to offer a better alternative to the client. Part of being professional is remaining positive and helpful.

Reframe their Problem

What if instead of sending a design mock-up, you sent a business solution? The difference is in how you present your design. This framing starts from the time the client initially contacts us.

    I ask...
  1. "Why are you looking to start this project?" to reveal their motivation.
  2. "What problem are you trying to solve?" to determine their pain.
  3. "How will you know if this project is successful?" to find what metrics are important.

While this is very helpful in crafting a brief, it lets me tie my designs back to their initial reasons for hiring us. When I send the design to the client, I present in the context of why they hired us. I might say something like, "Based on what you told us in the kick-off meeting, this is a great solution to X problem and will increase Y metric." For a particularly complex design, I will submit it with annotations describing the reasoning behind certain elements and how they'll help accomplish goals.

Borrow Credibility

Sometimes just telling a client that in your expert opinion a solution will work isn't good enough. That's when it's time to borrow credibility through design testing. If you're truly convinced of your design, test it.Send a survey to between 25 and 100 people and ask their opinion.

  1. Present two designs and ask which is better and why.
  2. Test usability by asking users where they think they should click to perform a task.
  3. You can even test subjective issues by asking how a design makes them feel.

Ideally your test-takers should be in your target demographic, and preferably existing customers. As a business owner, your client can't argue with 50 of their own customers.

It Gets Better

Always remember that the client hired you because they think that you can help them better their business. All relationships take time to develop. In time, you'll go from hired hands to trusted advisor.

Approvly

To help other designers get through design approval process and get feedback better from clients we put together Approvly, an app that takes the pain out of approval. Head over to approvly.com, and enter your email address to follow the progress and be the first to hear when Approvly launches.

Leanne asks...

How do you handle final payment when the site launch is delayed? We require 50% down payment for website design projects and the remaining when the site is launched. But lately, we have found customers are delaying the site launch thus we don't get final payment. How do you handle it?

We bill 30/30/30/10 with net 15 terms.

A client's payment schedule is tied to their project's milestones:

  • 30% deposit upon contract acceptance
  • 30% on approval of Photoshop document of final design
  • 30% on approval of HTML/CSS files of final website
  • 10% balance due when site goes live

By the time the site is delivered, we've already received 90% of the project fees. We've both mitigated our risk, and attached our payments to our performance. It's everyone's best interest to work this way.

Within 24 hours of Apple announcing iOS7, we downloaded the developer preview to our own phones.

It is the biggest refresh of the OS ever. It's a welcome change as iOS was starting to feel stale, especially in comparison to the animation love-fest of Windows Phone. Every single thing in the OS has been redesigned, so there's too much for us to go over in detail, but let's talk about a few features we've noticed and loved:

  • Accelerator based animations: When the phone is tilted, the icons and wallpaper shift slightly to give the phone a subtle depth. It's both superfluous and amazing.
  • Multitasking: The new task switcher works like the old WebOS from the the HP TouchPad. Swiping an app's "card" up off the screen closes it. Much handier than the old method. Supposedly multitasking has been rewritten to improve battery life, but we haven't noticed anything yet.
  • Camera: The new camera includes a square crop for the Instagram fans, a nifty new interface, and even filters with live preview.
  • Control Center: From the lock screen, swiping bottom-up reveals a new control panel with toggles for wifi, bluetooth, and brightness. It even includes shortcut keys and a flashlight. Finally, a flashlight.
  • Photos: New albums can be generated on the fly according to date or location. It's like iPhoto.
  • App Store: Apps now auto-update in the background (like Android.)

Aside from the new and beautiful interface, there's dozens of new features. It's exciting to see Apple update our favorite smartphone, especially with a design language we hope to see continue in to OSX. Overall, I like iOS7. Admittedly, it's in part because it feels so new and different. It's bright and tries to present itself as fun. It screams, "Computers are fun!" and I'm okay with that.

Dedicating 20% of our time to personal projects and research is the secret sauce that makes our client work successful.

We call it Ethercycle Labs. Its shaped our culture in to one of open exploration, let us take risks that clients couldnt, and given us insight on everything from the landslide shift toward mobile to the dynamics of crowd-funding.

To explore projects outside of clients demands, we began a Labs initiative in March 2012. The Labs program allows us to catalyze new thinking while getting into the consumer mindset. This research has provided us guidance on what to support for our clients, helped us reach new customers, and just generally been a great learning experience for the whole team.

Sharing everything we do publicly for free has been our best advertising. Our labs projects are almost universally things we built for ourselves that we shared. Collectively, those releases generate up to 1 million page views monthly, resulting in a lot of referrals to Ethercycle, and subsequently new leads or newsletter subscribers.

Explore what you can do with no restrictions, share it, and see what it can do for your business. At worst, you'll have learned something. At best, you'll have made something wonderful.

In 2009, I quit my job to launch Ethercycle. Back then being a consultancy hadn't crossed my mind.

Quite the opposite, I wanted to build an ecommerce SaaS app for bike shops. A little over a year after we started, we realized that our business model was flawed. We had made ourselves too dependent on other people. At the same time, we had met a lot of people who misunderstood what we were trying to do. These new friends did, however, understand that we knew the Web, and they would often ask: "Could you maybe help with our website?" Looking at the problem rationally, it became obvious that we needed to pivot.

Startups typically need to pivot and evolve their business model over time, especially as customers start to use the product or service. In order to pivot and keep your business moving forward, set limits. If a business model isnt working, you have to set a limit on saving it.

Decide in advance, before your emotions get the best of you, how much time, money, and effort youre willing to put in to iterating a business model before accepting that it isnt working. Failure doesnt have to be scary if you embrace it early, learn from it, and move on to the next thing. The last thing you want to do is rearrange deck chairs on the Titanic.