Buying on Mobile

Default blog image of logo on blue
Buying physical products and real-world services on iPhone

Shopping is changing

Shopping habits are changing. Even a few years ago online purchasing was treated by many with suspicion, whereas now e-commerce is often quoted as ‘killing the high street’. Looking into the future we’ll most likely see increased purchasing via mobile and particularly custom built e-commerce apps.

This will be not just for digital items but physical products and services too.

We asked our friend Richard Burton to do some research for us on iPhone e-commerce and thought we’d be so kind as to release his findings to all of you.

Research

Over the last couple of weeks I’ve been researching how people can buy physical products or real-world services on iPhone for Brightec.

In-app purchases of digital items are, thanks to Apple, very smooth and well-defined; buying and downloading bits is relatively simple. The process of paying for (and taking delivery of) things made of atoms and real-world services is largely left up to the people who make their apps.

I downloaded dozens of apps to look at their purchasing flows and took hundreds of screenshots.

In nearly every case, the purchasing flow was account driven - you had to be signed in and link your card to that account before you could make a purchase. This makes a lot of sense; once the card is saved and stored it’s much easier for a customer to make more purchases in the future.

Bits, services & atoms

It’s important to draw a distinction between the different kinds of apps that I looked at. I ignored ones that only sold through in-app purchases (bits), spent a little time looking at apps with real-world results (services) and primarily focussed on apps that deliver physical goods (atoms).

Services

Services like Uber, Instacart & Sprig all deliver on-demand, real-world services through their apps and the payments occur in the background. They’re abstracting away the card-entry process and massively reducing hassle.

Atoms



Buying physical goods online is an exercise in delayed gratification as you endure the obvious but somehow unsatisfactory waiting period after you’ve paid. Until 3D–printing improves enormously (assuming it will) there will always be a delivery process that needs to be managed.

One thing I noticed whilst playing around with a lots of store-focussed apps is that they don’t manage the post-purchase process particularly well. The delivery notifications are usually issued as unhelpful emails or left up to the delivery companies themselves.

Logistics companies tend to be run efficiently but generally have terrible interfaces for customers who are curious to know the answer to the most important question:

When will my stuff arrive?

This is linked to the next source of worry:

Will I miss the delivery?

During this research phase I had an unexpected (but delightful) message from Parcelforce.

As you can see, this text gave me the option to ensure that my package arrived safely even though I wasn’t at home for the delivery.

This SMS-based interface got me thinking: Why can’t I do this for all my purchases ahead of time and right from within the app? Why is this really useful feature being defined and owned by Parcelforce when it could be a huge opportunity for the company I purchased from?

This was my first idea for how buying on iPhone could be much less painful. I continued to add to items to this list in the research process.

Studies & posts

There’s been lots of research on how to design mobile checkouts for the web and I think a lot of this can translate to app-based mobile stores; here’s a selection of the most interesting posts:

The best of the three posts was Smashing Magazine’s huge study of mobile commerce usability. There’s so much detail in the post and it’s well worth a read—the 10 key pieces of advice were:

  • Make the homepage easy to scan.
  • Be sensitive to people’s fear of losing their data (or progress).
  • Place an “add to cart” button to the bottom of product pages.
  • Avoid animated carousels of product images.
  • Be careful with nested pages for larger images and other purposes.
  • Don’t force people to create accounts. Give clear choices.
  • Use autocorrect in the right places and avoid it for fields like email.
  • Make input fields large and the labels above them.
  • Use calendar pickers for date-input as opposed to numbers.
  • Make the hit areas and “tappable” items such as buttons really clear.

Buying shorts

Whilst searching for a new pair of shorts on a few apps I wrote down all of the questions that popped into my head:

  • Why doesn’t the app realise that “ahorts” is a simple misspelling?
  • Why can’t I see my previous searches?
  • How long will those take to deliver?
  • How much will delivery cost?
  • Is that colour and size in stock?
  • What size are they?
  • Why do I have to go to a new page to see the sizing chart?
  • If I go back to the store section, will I lose my progress in the checkout?
  • Can I return these if I don’t like them? How hard is that?

Very few apps answered all of these questions and none of them answered the right ones at the right time—this became another point of focus.

Sketching

With a few ideas in mind, I then started sketching out different flows, features and ideas. As I thought about the different things I wanted from a store-based app I realised that I often found myself in one of two buying modes:

1. Browsing: Sometimes I was just flicking through categories and searching for inspiration. I didn’t have a specific item of clothing in mind; I just wanted to see what was out there.

2. Searching: Most of my shopping is very focussed on a specific outcome. I wanted some smart, slightly-below-the-knee shorts and and I was on a mission to find them.

These two buying modes resulted in me a adding selection of items to a basket, making a conscious decision to finish the shopping process, paying, and then await delivery. This became the flow I sketched around:

Shopping→ deciding → paying → receiving

I, the customer, cared about finding the right things, paying for them quickly, and receiving them as soon as possible. The companies were delivering things to me and I hated missing those drop-offs. This was the flow I wanted to make better.

Prototypes

I decided to focus on a mobile app for a clothing store and think about the kinds of things I would have liked to have seen in an app when I was searching for some shorts. I used Topshop as an example brand.

Browsing & searching

The Topshop App kept the search bar ever present at the top of the screen. Major clothing categories are listed at the top and brands below. This is the layout that was recommended in Smashing Magazine’s review.

Once the search section is tapped, the screen is focussed on the text input and recent searches are loaded. If the customer makes a mistake, alternatives are suggested using Google’s unofficial autocomplete API.

Checking out

The most important things about the checkout were data persistence, reducing the number of fields to the bare minimum, and allowing a customer to buy something without an account.

I thought it’d be interesting to incentivise logging in or signing up with small discounts: In other concepts I played around with a camera-based card scanner that uses the freeCard.io API from PayPal. I’ve noticed that this is used by Uber to great effect.

Delivery Notifications

Finally, to conclude my research, I also experimented with different notification styles, including some interactive ones. I think it’d a much better experience if the brand that sold you the clothing also owned the delivery process.

I hope this research is as helpful for you as it has been for myself and the Brightec team. We'll be eagerly watching developments in this field over the coming months & years.


Looking for something else?

Search over 400 blog posts from our team

Want to hear more?

Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!