Product info on a lot of retail sites in my experience is restricted by legacy databases and info available from the retailer and their 3rd party IT. The website doesn't exist in isolation, as the article mentions, users want to see availability of an item ("only 3 left, order now and don't miss out"). There's your clue there. That data is linked to ordering and logistics data, often for a chain that operates hundreds of shops, including brick and mortar shops. Retailers want _all_ of the inventory available at all times, especially in season driven textile retail. Once the season ends you either sell it at knock down price or discard it.
Transfer of stock between brick and mortar locations and the central warehouse happens. Stock is ordered in 3-6 months in advance. Retailers ideally want zero of an item in inventory when new stock arrives.
The data discussed in the article is part of a much bigger system with integration left and right in a much wider spectrum than is being discussed in the article. Not that that shouldn't spur everyone involved into action; creating the solution that increases sales the most, just that it isn't as easy as this guy makes it out to be.
Completely agree. This article helps highlight that one of your most important systems is your PIM (product information). without a decent PIM you can't server the right data to your PDP.
Unfortunately PIM upgrades aren't 'sexy' projects vs re-designing your website (for example) where you get to look at lots of lovely UI, so often it never gets neglected (in my experience).
Of the points the article mentions, the one that I agree with most is 'taking over zoom'. This is probably the worst design mistake I've seen with mobile websites. The user should almost never be restricted from controlling the zoom level on a mobile website (the only exception I can think of is resetting the zoom level on a webpage refresh), regardless of how much a designer wants to control the user experience.
It's funny how stuff like this is so important, but can go to the back of your mind when you're thinking about DOM rendering or 99th percentile page load times or similar.
Yes. The best way is probably to physically/temporally separate the phase of working on the design and product from the phase of working on the code. This has some conceptual benefits (thinking more freely when you don't have your tools in hand) but I also find there's a more straightforward issue of energy or cognitive stamina.
Some of these items are really difficult to make, such as a zooming viewer. It took me several years to get one that was right. Try to make one that works on mobile & desktop, doesn't crush your bandwidth, & operates at 60fps. There are so many plug-ins but none that feel exactly right.
The large collection images, you can click/tap/pinch to zoom in. You can also pinch (on mobile) or thumbwheel/swipe up & down (on laptop/desktop) to change zoom level. Try it with Safari an MacBook Pro/iPhone/iPad for best results. Other browsers are supported but features tend to degrade.
Right now the code is tied tightly to my image gallery viewer, as well as my specialized Django backend and even my own custom single-page-app framework that isn't Angular/Ember/React.
If there's enough interest I can make these components usable by others as separate componnts. There are still some features I need to add, like sharing and more interaction controls (keyboard, swipe, etc..)
This is why engs don't make great product designers. They are concerned with the very important foundation and performance, which doesn't leave much cognitive overhead for the actual UX.
a consumer product will not be competitive without both the foundation and the experience being top notch.
For iOS, we have a product that automatically makes many improvements to load times and latency to allow engineers to focus on UX/UI rather than low level perf like so many do
A perfectly reasonable observation but I'm sure there have to be counterexamples of engineers who are great product designers. Now I just have to go and find them :)
Rule of thumb for mobile web (not app, web) is that conversion rate is roughly half (so: 4% desktop web, 2% mobile web). Source: Google analytics of several companies doing > $20mm annually.
I know it's not a popular opinion here, but the only way you approximate or beat desktop web conversion rate and average purchase size is through building a well done, native ecommerce app.
Re: native: sounds like a selection bias-- a user who has gone through the trouble to download an app from the app store is already an interested customer with some degree of brand loyalty, versus your regular mobileweb visitor coming from organic, paid, email, or social, who may not yet have any relationship with the brand at all.
Certainly that's true, but I think you might be missing my point: it's not an either or - you need a non crappy mobile website for discovery/top of the funnel stuff. But from experience, if you don't want to resign yourself to half the conversion rate as more and more visitors come on mobile, you need a native app. If you don't do it, some "mobile first" startup will, and eat your lunch.
Successful store owners don't like to share these kinds of numbers, but I can tell you that per ad dollar spent, it's been better than web for a responsive site I manage that shouldn't be very mobile specific.
This might be because other store owners don't bid up mobile as much so that the customer acquisition via mobile are cheaper.
With a lower conversion rate, assuming identical order value, the earnings per click will be lower on mobile than desktop. So with a $100 AOV and 5% CVR, your EPC is $5 per click.
With mobile, the CVR will be lower (at least from my experience), so your EPC may be $2.50 per click with a 2.5% CVR.
If you're converting worse, you just pay less per click. So if you want your ad expense to be 10%, with desktop ads, you can pay $.50 per click, versus only $.25 for mobile. Google's inventory growth has only come from mobile, which converts worse, so it is essentially less valuable. Google has mitigated this by increasing AdWords CTR, which increases their earnings per mille. YoY I've seen AdWords CTR increase ~30% on mobile, likely due to the green ad labels and increased spacing between ads that push organic results further down the page.
Google is pushing hard to get advertisers to actually bid more on mobile, even though it converts worse, by eliminating metrics such as Cost per Converted Click in favor of Cost/Conversion (which attributes conversions across devices. Until recently, Desktops & Tablets were lumped into one bidding category, the latter being the worst performing of all 3 devices, the former the best) and pushing equally opaque metrics such as Store Visits. The Store Visits functionality is touted as a huge way to measure cross device in person conversions that big brands with huge, inefficient budgets love (clicks desktop ad, visits store and store visit is logged by phone), but having worked at an out of the way retailer who would be closed on major US holidays, Store Visits held steady even though stores were closed. There isn't anything you can really do, though, since over 90% of all US search traffic is Google.
Yeah, the decoupling of desktop and tablet is a big deal for us, our tablet conversion rate is currently pretty similar to mobile but we have had to pay roughly double per click over mobile to have the bids correct for desktop.
Lots of good advice here. The one but I'd question though is:
"Always try to detect user’s location automatically"
This is risky. For some people, there may be nothing more off-putting than browsing a product page and seeing the 'we want to know your location' pop-up.
Also, just because you know their location at this point, it may not help in identifying their most convenient pick-up location.
The rest of the article places a lot of emphasis on user choice, which is good - so why not just do this for Click & Collect functionality too? If I like a product, let me choose where I want to pick it up from during checkout. Don't force that decision upon me when I'm browsing a product.
There are counter-arguments. Perhaps if you can show a nearby store has some in-stock, you've got more chance of a successful conversion. Might be worth A/B testing, but it also depends on your geographic distribution of stores (if the closest store is several miles away, probably not worth doing all this automatic detection on the PDP).
Overall though very insightful article and lots of good points. thanks!
Its not that it isn't obvious, just that sometimes your focus is on other things and you forget to think of these things.
At large organizations you might have a designer, product manager, front-end developer, and back-end developer and you can isolate their thinking to individual parts and make sure not to miss these things.
In a smaller organization your front-end developer might also be your designer and if they are focusing on scrolling performance, responsive design, or unit test coverage the UX might end up being something in the back of their mind and gets less time/focus.
Development is all about making trade-offs with your time, you rarely have a "finished" product. A lot of times what we do is build out MVP as quick as possible and then A/B test changes to KNOW they are making a difference. A lot of UX things that I assume are obvious end up losing in our A/B tests.
Transfer of stock between brick and mortar locations and the central warehouse happens. Stock is ordered in 3-6 months in advance. Retailers ideally want zero of an item in inventory when new stock arrives.
The data discussed in the article is part of a much bigger system with integration left and right in a much wider spectrum than is being discussed in the article. Not that that shouldn't spur everyone involved into action; creating the solution that increases sales the most, just that it isn't as easy as this guy makes it out to be.