What do developers need to know about store design?

 

For the past 10 years, our design consultancy has run a service that coordinates with internal teams to improve their stores. We do this in three steps:

  • Research customers. Figure out what they’re saying, through interviews, usability tests, and surveys. Figure out what they’re doing, using analytics, heat & scroll maps, and behavior recordings.
  • Make improvements, both through one-off fixes and ongoing experiments.
  • Measure the impact, usually through analytics or ongoing interviewing.

Investing in store design

If you’re a developer reading this, and your clients aren’t thinking about design yet, you should consider raising the issue to them, because:

  • Design has a reliably positive ROI. All businesses exist to get a solid return on their investment. Design has a high ROI because it fundamentally exists to address customer needs.
  • Development can only take a store so far. Usability might break. Customers might not appreciate what the store is selling. Or they might have objections about the sale itself. Without design, there’s no way for a developer or store owner to know what’s going wrong.
  • Design minimizes customer acquisition costs. That’s an ecommerce-beancounter way of saying that design focuses on the profit motive. Customer acquisition is always going to matter.

Design is not just a matter of branding or illustration. As a reasonably smart guy once said, design is how it works. Design is how you communicate to customers and address their needs. Its principles are evergreen, regardless of what clients you serve. (Heck, you might want to learn more about practicing it yourself.)

How to approach store design as a developer

Normally we work with a client’s in-house developer or, when they don’t have one yet, we introduce them to third-party agencies that we trust. We’ve been grateful & honored to partner with many wonderful Shopify developers over the years, and we’ve learned a lot about how to coordinate with them.

In writing this article, we reached out to most of the developers & agencies that we’ve worked with since 2012, as well as several others who perform similar activities. We asked them what kind of workload to expect when working with a value-based design consultancy like ours, and what matters the most when considering our work together. Here’s what we learned.

Optimization workloads are generally small

Everyone I talked to said that optimization workloads are generally low-cost & high-reward to clients. This is for a few reasons:

  • Changes are pretty simple, usually around content, messaging, and small layout tweaks
  • Many developers are used to handling all of the project management, estimation, and prioritization themselves, which are now offloaded to the designer
  • The client feels generally happier that the team is making numbers go up in a way that generates outsize ROI

Developers can set up a flex fund to handle most of these changes, with a maximum of 10 hours per month. That gives them the space to suggest other maintenance activities, especially around performance optimization, re-theming, and app audits.

Leave prioritization to the designer

Any value-based designer worth their salt will have a solid approach to prioritization. Here’s ours. They should be the ones to direct what gets fixed, when, and how.

Provide pushback, of course – there is often an easier way that still gets us across the finish line – but ultimately, the initial call falls on the designer.

Be clear about turnaround times

Working with others requires sitting on the same side of the table, and making yourself available for the work.

Use contemporary communication tools like Slack & Trello, not just email. Stay present in there to answer questions as they come up. Resolve blockers. And be clear about how long something is likely to take.

Build feature flags to make big experiments easier

In experimentation parlance, a feature flag allows for easier rollout of a particular variant in the testing framework. That can take the form of:

  • An element that’s hidden by default using CSS, and un-hidden in the experiment’s variant
  • A feature that’s turned off via JavaScript, and turned on in the experiment’s variant – which is especially useful for rewriting elements or changing multiple things on a page
  • A personalization that applies to a dynamic segment of your audience, such as those who spent a certain amount on previous orders, or those who typically buy in bulk
  • Experiments that run across many pages at once, such as for new themes, objection-busting, or major pricing reworks

It’s easy to build a feature flag system once, reusing it for future experiments. Make sure to take the extra time to build in this flexibility when you’re first requested to do so for a client.

Keep your theme flexible

Contemporary themes allow for team members to update their headlines, images, and page copy without much developer intervention. This makes everyone’s lives easier as they roll out winning experiment variants and one-off fixes.

If your theme doesn’t possess such flexibility, it might be outdated, and a re-theme might be in order to get back to an acceptable baseline from an operational standpoint.

Wrapping up

Every developer is different, and every designer is different. But we’re all on the same side of the table at the end of the day, trying to make things better for our clients. Through clear communication & well-set expectations, we can make the process as frictionless as possible.

After all, designers generate work for developers – which, I reckon, is a good thing for everyone.

If you’re interested in collaborating, or you’re a store who wants to increase their conversion rate before Q4, take a look at our past work & get in touch. Thanks for reading!

← Back to the Blog Check Out Draft’s Store →