From Mockup to App-Store
In October 2014, Project A invested in Catawiki, an online auction house exclusively for exceptional collectibles and unique items. Our goal was to help them expand and internationalize their business, providing financial investment and operational expertise. Founded in 2011, Catawiki holds weekly auctions in 35 categories, providing a platform to unite buyers and sellers, resulting in transactions of tens of millions of euros each year. Specialized auctioneers supervise the auctions, with their expertise guaranteeing a large variety of high quality lots (“lot” is an auction term meaning an item up for bidding). Each auction contains a diverse number of lots, all pertaining to a specific topic.
Beyond supporting their marketing and BI efforts, our team identified the importance of immediately notifying users when they are outbid, allowing them to react quickly and avoid losing an auction. To provide the users with the fastest possible bidding experience, we decided to create an iOS app, taking Catawiki mobile and bringing the auction experience to the smartphone.
We focused our initial development efforts on iOS exclusively — rather than two platforms at once — in order to provide our users the best designed, most bug-free experience possible, as well as to save time and money.
In this blog post I’d like to walk you through the evolution of the app, taking look at the design of several different areas over a number of stages. We’ll go over the design process, and I’ll explain why changes were made to the design of particular areas. The changes we applied are based on user feedback and on mobile best practices.
Auctions Screen
We start with the first screen the user sees when he opens the app: a list of all auctions, starting with the auctions ending soonest.
As you can see in the GIF, the transition from mockup to final app involves a number of changes:
Reduction of functionality:
- We found that the “Pin the auction” feature distracted the user, so it was removed.
- The “View all Lots” button, which was designed to show all lots available in an auction, was removed because users don’t need a button to go to the details of an item; they know to tap on a particular item instead.
- The display of the auction’s ending time moved to the header
- We reduced the size of the auction item to display more auctions on the screen (from three items to four)
- We started with one picture per auction. The feedback we got from users was that they want to see more preview pictures to get a better impression of what to expect. Accordingly, we first increased the number of review images to four, and later to five, in order to provide a more complete preview of what the specific item looks like, and to give the users a better idea of what to expect.
Lots Screen
The Lots Screen shows the lots of a particular auction, and is updated in real time: for example, when a new bid comes in.
In this case, we changed the mockup by removing the “View the lot” button for the same reason we removed the “View all Lots” button.
Bidding Screen
The bidding screen allows the user to bid on a lot. There are two possible ways to place a bid: by tapping on “Place bid,” or tapping on “Automatic bid”. “Place Bid” allows the user to fill in an individual amount, entering a single, one-time bid for a specific value. “Automatic Bid” allows the user to set a maximum amount they are willing to bid, up to which their bid will automatically be raised in response to another party bidding on the lot.
The two input fields were removed due to user confusion over having two text fields.
- The text explaining the auction fee was changed to an explanation alert.
- An image of the lot was added to the screen, to make it easier for the user to connect the bidding screen to the particular lot
- The size of the information bars at top were reduced in order to allow the user to focus on the bidding.
After we finished and launched the final version of the app, it was downloaded many times before we even began marketing, and we have already received very positive feedback from the users. This shows how crucial it is to allow an app to evolve through different stages of development, and to not be afraid of making fundamental changes. Another essential aspect is to provide your test users the ability to try the app directly on their phone, as well as to test in an interactive modus (I’m not sure if you specifically want to the word “modus” or not. If not, I would change it to “manner”). Doing so will make their feedback much more valuable.
The changes we made during the development process have been very important to the success of the app. My advice is to not hesitate to change the look and feel of the app while you’re developing it. The most important questions you should ask yourself when thinking about mobile user interfaces is “What’s the job the user want to be done.“ Then, with the early feedback of your test customers, try all possible avenues to create a solution which is the simplest way to get the job done.
