
Mobile eCommerce: Product Details - babich
https://uxplanet.org/mobile-ecommerce-product-details-28feba377a55#.9exz2hdq3
======
kagamine
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.

~~~
chatwinra
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).

------
ZenoArrow
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.

------
nstj
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.

~~~
tsunamifury
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.

~~~
wittedhaddock
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

[http://createwithcaffeine.com](http://createwithcaffeine.com)

~~~
tsunamifury
why not just let the designers focus on that.

~~~
wittedhaddock
They totally can. Main point is that we free up all engineering hours
otherwise spent on optimizing performance.

------
robryan
Does anyone here actually get mobile website conversions comparable to
desktop? (Without having a brand which customers see as primarily mobile).

From what I have seen and found in online survey numbers they are far lower.

~~~
einarvollset
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.

~~~
joshwa
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.

~~~
einarvollset
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.

------
chatwinra
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!

------
popdoit
This guy is still posting? He blatantly copies other articles.

~~~
nachtigall
Source?

------
ahm750
Just right in time. Was designing a products page today. Thanks for sharing!

------
johansch
At least 90% of these would be self-evident by someone.. ehm.. intelligent.

Then again, I keep seeing these issues on websites, so...

~~~
sontek
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.

