• Project type: Freelance
  • My roles: End-to-end iOS product designer


Amazon's sales ranks are critical information for an independent author's business, but accessing them on Amazon's site is tedious and time consuming.


Independent authors could perform faster market research with an iOS application that allows them to create custom lists of books to track their sales ranks.

Project highlights

Client collaboration

An old colleague approached me with an idea of creating a new iOS app to help independent authors track Amazon sales ranks for books.

Research redirect

My user research challenged the assumptions and hypothesis both the client and I had made, leading to a direction shift for the product.

Visual struggles

Creating a comprehensive UI kit for the product pushed me to reach far beyond what I thought I could do in visual design.

Stalled development

Due to budget constraints, the client hasn't been able to hire a developer with the necessary Amazon knowledge, so development hasn't started.

Defining the problem

Brief and MVP requirements

The client had already done extensive secondary and market research (which is under NDA). We had a brief stakeholder interview and hammered out a few "must have" features for the app MVP.

Though the client wants to expand into the Android market eventually, due to their development budget, they chose to focus on iOS first.


Field user interviews

Though the client had already done deep secondary research, I wanted to validate their conclusions with my own primary research.

Coincidentally, one of self-publishing's biggest professional conventions, 20Books Vegas, began as I started work on the project. Because I live in the area, I spent an afternoon interviewing 5 self-published authors at various stages of their careers in the ballroom of Bally's casino.

Outlining users & needs

Based on my interviews and the client's market research, I outlined four personas that reflected authors where they were at in their careers. These personas forced us to make some tough decisions about what to prioritize.

In the end, the client and I decided to focus on delivering the ability to create custom lists of books to track ranks, since that functionality would address a common pain point among all our personas.


The client wanted to create a tool for authors to research their competition, but my research indicated authors were more interested in their own books.

Ideation & testing

Maps & flows

Though research made it clear most authors only wanted to check and track the sales ranks for their own books, we decided to design the app to be flexible enough to allow users to look up and track any book they wanted, including their own.


Sketches, wireframes, & prototyping

To validate we were on the right track with the design, I created a mid-fidelity prototype from these wireframes and tested each of the six core flows I'd outlined:

  1. Searching for and adding a book to a new list
  2. Searching for and adding a book to an existing list
  3. Editing and rearranging lists
  4. Editing and deleting lists
  5. Deleting a book from a list
  6. Pinning a book to the homepage
Mid-Fi Prototype Recording

User testing

Conducting user testing was a challenge because the client was very concerned about having the concept stolen. To get around this and having to draft up NDAs, we agreed to test only with independent authors the client and I personally knew and trusted. This necessitated remote testing. Thankfully, it worked, and revealed some key insights:

  • The test ran with a duplicate book error that confused users and caused a high bounce rate
  • The language used in the "Add to list" modal wasn't clear enough
  • Participants didn't understand the design pattern we'd chosen for the "rearrange lists" feature
  • Participants were also confused by the list deletion flow

With validated core flows and features in place, it was time to move on to the daunting task of the visual design.

UI & branding

Branding and UI kit

I explored several different color schemes and visual identities for this project before selecting what's shown here. In the end, the connotations of money and calmness with the green palette won out for the client.

However, creating an systems-based UI kit for this app was a massive time sink that ate up twice the amount of time as anything else. While I'm glad the kit exists now because it'll make the developer's work easier, and I'm proud of the work I did to create it, in retrospect I don't think this is something I'd do again as a solo designer.


This project pushed me in unanticipated ways, and I can't wait to see it come to market sometime soon.



Next steps

Test high fidelity

Though the changes indicated by my user testing were minor, I'd still like to test the app again in a higher fidelity state — and preferably in a test that doesn't run with an error.

Prepare for developer handoff

The client hasn't yet been able to hire a developer (Amazon's API terms seem to be scaring them off), but I want to prepare my designs and files as best as I can anyway so that when a developer is hired, they're set up for success.

Prepare for App Store review

Shipment of this app is a few months off, so I have time to double check that the designs meet App Store standards and will pass review.


What I learned

Balancing client & user needs

Though the client is someone I know personally, working with them in a professional context forced me to learn how to advocate for users and when to compromise.

I am not my users

I spent four years working as an independent author and met many others so I thought I had a pretty good idea of what they wanted and needed, but they challenged my assumptions at every turn.

UI kits are time consuming

Both in terms of their overall complexity and requisite scalability. I'd never attempted something like this before, and it really improved my mobile design skills.