Designer in an early stage company, or how I designed ‘Read’
This post is the first part of my portfolio. I made a lot of mistakes while building Read, and one thing I learnt is to not reinvent the wheel, that is why I choose Medium to write my case studies. Today, they are the best layout all around the web. My first case is about Read.
Read is a free iOS app to read Epub that really helps pro-readers remember more from their readings.
I pursued research on e-reading after I wrote my Master thesis on digital gestures. My two previous iterations, Addr, an iPad app, uses collective annotations as an alternative reading workflow. Libr, a side-project, works like a P2P network and enables readers to share their ebooks within the app.
Together with Simon and augustin, in May 2015, we decided to build an ebook reading app. It would be iPhone-focused, data-driven, and without no social integration at first. A true productivity tool. My brother Simon by my side for my two previous apps (customer support, PR, investor decks). Augustin was looking for a new project after his previous app, Opus, a recommandation service for books and movies ; he completed the team with his tech background. At first, we thought ourselves as a studio iterating around one core question: how to read on a screen?
Our job was to foresee what readers will look for when reading on a pocket computer in the near future. We had built our two previous reading apps for iPad-only. But we soon became focused on the iPhone since we received a lof of feedbacks such as:
I only read with my iPhone 6, I just can’t use your apps!
We thus bought and tested reading on iPhone 6 and 6+, and guess what? they are totally right! Screens are largely big enough to have a proper reading experience. And it feels natural to pull our mobile out, anytime, anywhere. We thus believed in “mobile first” before reading Ben Evans’ blog.
Where we explore the habits of e-reading.
After some interviews in libraries, bookshops, and even outside an Apple Store in Paris, we discovered that ebook was in large majority, related to PDF. But we knew that we couldn’t improve the PDF reading experience. It has been conceived for the print industry. And no technology exists yet to convert 100% of PDFs into reflowable documents. We never seriously thought of working with PDFs since we wanted to solve the reading experience by design.
From our launch Medium article:
We’re convinced Epub will eventually replace PDF as the standard text-format. Primarily because users can personalize fonts, margins, and more. With Read we wanted to change the way books are perceived. After Pocket, Medium, and Flipboard, we think that ebooks and web articles will eventually merge.
Where we draw Jared in Trello.
So who reads Epub? And who over-uses mobile?
From there, we draw a persona and named him Jared. We spent some time to find out his tastes are. What does he like and dislike? What are his daily routines? We found five fields were Read could be helpful: 1- apprehend digital books, 2- reflect his identity through his digital library, 3- keep a blue print of reading, 4- produce content after reading, and 5- recommend books. We put everything we knew about Jared in a Trello board. We have used it regularly since then to add content, and to think of Read’s big picture.
We thought Read as a coup against iBooks. I still think it is possible to hack the standard apps given on an iPhone with a smart design. Sunrise, Wunderlist, and Mailbox did manage to convince early adopters to switch for a nifty designed product. Also, it shows how much integrations enhance our daily experience as users. And this part matters maybe more than drawing a new set of icons.
Where we define our workflow.
We knew that the way we work has a huge impact on product. So, from day one, we decided to fix three rules until we would gather enough users’ feedbacks: 1- ship as fast as possible, 2- build a few but solid features and 3- keep a minimalist framework for the UI.
I designed Read for iPhone first and let the iPad optimization for later. I finally never made any iPad wireframe. We have coded the iPad version directly from Xcode, with relative values for views and positions, and absolute values for the pictograms’ sizes.
We met a peer-coding evangelist during a Google Launchpad in Paris. We were in a very good position to adopt this method because Agustin and I both code in Objective-C. I think there has been three reasons why we tried peer-coding and loved it: 1- we will be fast because it avoid all little mistakes during coding, 2- we will write intelligible code, and 3- the team members who don’t code are relaxed about the coding process, because both of us can debug any part of code and push it in “prod” at any time, from anywhere.
How to deal with ambiguity.
When we had to code some redundant classes and re-write some functions, Augustin quickly did the job while I had the time to craft some mockups. I showed some JPEG to the team and we implemented it right away if it didn’t require any new skill on the Objective-C side.
When people asked us what did I do in the team, it was hard to answer. I was responsible of the visual wireframes. But we were peer-coding with Augustin most of the time. When prototyping, it did help a lot that with few variables in Xcode, I could quickly adjust colors, sizes or interaction animations. Again, our first goal always has been to ship a product, and updates, as fast as we could. And with all the trackers that we implemented in the app (all plugged onto Segment), we used as much data as we could to help us build the product.
A productivity tool
Where we define the products boundaries.
Read was supposed to be, at first, a productivity tool. We thought Read as a hub between inputs (sources) and outputs (highlights, quotes), where readers could store data for later.
Our initial questions were:
- What is the one and only task we want to improve compared to the competition?
- Which are the essentials options to implement for day one?
- How do we add value with third party integration (APIs) and how do we integrate them?
- What is the primary action we want users to take on this screen?
- What might prompt a user to take this action?
- Where do we put sniffer and what is the naming convention?
We decided to work on:
- Import books via Dropbox
- Synchronize highlights with Evernote
- Customize reading experience
- Synchronize books between device
- The weekly email with all the user’s highlights
- Building a minimalist UI
As an app that had the ambition to become the best tool for reading, it was really important for us to stay focused on one single problem to tackle. For example, we have had hundreds of requests to add annotations, social sharing, or to support PDFs. People quickly try Read and ask for what they see in other apps without using our original feature. That said, we added a very user-friendly Feedback field from day one in order to have as much insights as possible.
For us, a productivity tool meant: 1- single task focused, 2- moderate customization and 3- APIs first.
We focused first on the implementation of two APIs (input and output) plugged into our own “Epub Engine”. This wasn’t about designing new buttons nor any smooth transition from one screen to another. Neither didn’t we spend that much time on branding.
Read follows the minimalist guidelines. White is the dominant color. And two screens are enough: 1- the home Library and 2- the reader view. The home Library is a list of ePub files ; inspired by Pocket (articles) and iTunes (songs). At first, we didn’t add many infos in the book’s cell. The reader view is plainly generous: a full screen of text.
Designing a mobile hub (1/2)
Where we connect Dropbox
Read does not provide any content. It is up to the user to download his own ebooks. So we constantly tried to facilitate this very first step: fill the app with user’s books.
Ebooks are mostly stocked in Dropbox and Drive. Do not forget though that ebooks are files, from 200Ko to 50Mo, some contain dozens of pictures. We faced two issues: 1- the file weight and 2- the amount of API calls. First, to get a book’s metadata, the Epub file is “unzipped”. But “unzipping” hundreds of books at once takes long time, even with an brand new iPhone 6s. Second, many users have a huge amount of data in their own “Cloud”. When Read crawls through 1To of data in Dropbox architecture to retrieve the Epub files only, the app would crash because of the massive API calls.
This is mostly why Read does not download automatically every Epub files available out there. Read manages stocks, not flows. We thus have to make it easy to add ebooks manually, with a simple Add button. (And we forget the idea of a Refresh button…)
The user has to be pro-active, it is not like social or news apps where users passively scroll through a sort of newsfeed updated in live. With Read, we consider a user “locked” when he adds three books or more into the app. These users came back each week and spend more than twenty minutes per session.
When the user clicks on the Add button and next in ‘My Dropbox’, we wanted the users to access directly to all their books displayed in a simple view. It was a mistake for two reasons: 1- they don’t immediately recognize that these are their books. 2- If they have a huge amount of data in Dropbox and if their books are far away from the root, the app crashed before displaying anything in the view.
We improved this feature with something even more simple: Read shows the user’s Dropbox architecture. Users navigate through a familiar architecture they have themselves built, and find more easily their items more easily. Books are downloaded on the first click, then opened on the second click.
We now have a proof that our users have a lot of books in their Dropbox. Hundreds of them ask us directly to implement other services like Drive and Box.
What could we improve?
Christophe Tauziet once gave me an insight to reduce the friction of the repetitive action of uploading new books. Read could provide a sort of push notification for the user to import directly the last book added in Dropbox. It is all about anticipating what the user looks for when opening the app. This insight helped me figure out the power of a simple design to prevent from a redundant task.
Designing a mobile hub (2/2)
Where we connect Evernote
An average user highlights a text in order to focus on what he reads. Simon has interviewed dozens of pro-readers who save quotes to produce content later on. (Founded on Medium and Quora and Evernote’s forums.) Mobile pro-readers copy/paste one by one every highlight they take while they read. It is a really painful and repetitive experience for them. Simon describes our ambition in a Medium article:
Remembering what we read is a pain-point for avid readers. So how to save the quintessence of a book? We built the simplest tool for this. Read saves every highlight made into an Evernote dedicated note. And everything is synchronized between devices.
Our users also receive a weekly recap with all their highlights — plus various metrics like their total reading time Weekly recaps gather the highlights made during the week. Readers who didn’t finish a book are reminded of the work they’ve put into a book.
The highlight feature implementation is the best example I have to illustrate how software can influence UI choices — and for the better. Two objects refer to each other: 1- the button to highlight selected text (textMenu) and 2- the button to display all highlights taken (highlightMenu).
Highlighting is one of the core value for Read. We did in-depth user-testing while prototyping our MVP. We tested dozens of icons up until every potential user we met recognized the highlight pictogram. We asked simple questions: What this pictogram does means for you? Testers weren’t always sure the icon was related to highlights, annotations or quotes.
I then started to customize the default iOS textMenu, e.g the pop-up that appears after a long-press on a text bringing options like copy, define, and share. But it was a tricky code to manipulate. We decided to turn the problem around to go faster. If we couldn’t custom the textMenu in Objective-C, we had to conceive a highlightMenu pictogram based on the default iOS textMenu UI. In few hours, we have designed and implemented the new pictogram.
This pictogram is now dynamic, one can see the number of highlights increasing through time. It is an original, and gamified, way to see one’s progress into a book. A good news for coders sometimes appears to be really good news for the user.
There are many way to highlight a text on mobile. NeuBible, a modern Bible app, launched in March 2015. They implemented the long press gesture to highlight verses. We had tried this in Read too. It seemed good at first, but when we tried in real context to highlight a precise fragment of text, it sometimes did not work properly.
Take Belle du Seigneur by Albert Cohen for instance. The most famous passages do not have any ponctuation. So when I tried to highlight some line of text with the long press gesture, hundreds of lines were selected and highlighted at the same time. We thus learnt that less buttons do not necessarily make things simpler, but sometimes even less scalable (Jason Stirman in this article).
Where we dive into detail in typography
Choosing the right typeface is a complex choice, especially for users to test accurately. But it matters so much! Fonts help us to resolve two problems when it comes to e-reading: 1- reading long form document, 2- reading on mobile; iPhone 6 being the reference.
For typographers who care about confort of reading, it is pretty obvious that serif typeface is the best choice for the fluidity of reading. The average number of words in a sentence is 10 to allow the user to read in diagonal and increase the speed of reading. But mobile screens are smaller than paper pages.
I have a two rules system to choose the right serif typeface. The first is about the width of the screen: I searched for the fonts with the highest number of words that would fit in one sentence without modifying the spacing. The second is that the font has to have an eye very open. As Read offers five text sizes, I have to pay attention to the readability of the smallest text size.
The hard task here is to get more words per page without encroaching the experience itself. I try to limit hyphenations by choosing a font as narrow as possible while avoiding too much condensation. I choose the Tiempos, where most glyphs are narrowed, the spacing tightened, and the overall contrast adjusted for a mobile screen.
Where we set the limits
I like to distinguish between “productivity” and “power-user” apps. Some users love to feel the infinite power a settings menu with dozens of options seems to offer. Concerning the ebook apps, to much personalization can damage the way people actually read.
We made the choice of pseudo-customization. I made the opposite choice when I created my two previous iPad apps. I had blocked a default text size, line height, and margin size. With Read, it was impossible to only offer one single “typography settings”. We had to support a wide diversity of ePubs documents, like novels, essays, programmation textbooks etc. Each of these requires a different kind of settings. But it has never been in our plan, for Read, to offer a total customization of font, size, line-height, or color.
I think the “just enough” customization is the best solution (see Teehan+Lax Studio). Our role is to offer a few options while controlling more global parameters. For example, the alignement is set programmatically: if the user set a small text size, Read automatically set a justified alignement for the text. If the user set a big text size the text is left aligned since the number of words per line is less than 6.
It gives flexibility to the user and allows me to maintain a few, but fondamental, typographic rules. Another example is when the predefinition of the contrast between the background and the text color. Three options I calibrated myself are available: day, night or sepia.
Apple is part of the team
Where we learn to work with a new “employee”
The App Store is part of the project, and should be considered as a team member! App Store review should be tested way before launch to avoid any misunderstanding. The last update of a previous iPad app of mine, Addr, has never been approved because of its “social feature”. And Readability took over 100 days to be approved.
We already had experienced shipping apps on the App Store. This time, in late August 2015, we wanted to test a beta-version with a base of 300 users Simon had found manually. We decided to use TestFlight, Apple’s service for beta-testing. In a few hours we had 70 downloads and twenty feedbacks from friends, acquaintances and anonymous pro-users. Nice start! But two days later, we didn’t have any more feedback: the other “beta-testers” never received the email invitation. Since then, we met the CEO of Feedbooks, who told us he had the exact same problem. TestFlight did not send emails properly.
We then decided to submit Read directly to the App Store. The last remaining bugs were to be fixed eventually and we really needed more users feedbacks to move on. Ev williams himself tested a bugged version after Simon published Read’s first blogpost on Medium. And we stayed in touch ever since.
During this long week of “Waiting for review”, I worked on some UI since it was difficult to modify the UX without any new feedback coming from “true” users.
(If some of you aren’t satisfied with TestFlight, the Mindie team, whom we met a few weeks after, advised to use the Apple “Entreprise” program to reach up to 1000 users instantly. It seems to be the best alternative so far.)
Using the product
Where we learn to read hidden metrics
A Fine Arts student myself, it took me some time to separate the startup requirements from my own taste and values(e.g always be surprising.) It took me some time to get this obvious point: enjoying a product, and more precisely an app, is not correlated with any innovation in terms of gesture. When I used to demo personally M. Proust, the first app I coded by myself, I was pretty proud of the waouh effect it produced. But the app was not usable in the startup-way-of-thinking. People could not appropriate easily M. Proust since I tried to change some basic usability laws. I didn’t get that anticipating user’s gestures was the only law to follow in the real-life apps market. It is the exact opposite of what we used to do back in my Fine Arts School. In 2012, I wrote my Master thesis on digital gestures. I was thinking and writing about some of the new ways to interact with screens in our every-day life. With Read, users can spend hours to read and highlight without any prerequisite in terms of gesture. What matters for them is to enjoy reading on their screen.
Since we are Read’s first users, we quickly understood how to look at our metrics on Mixpanel. One interesting example is the “Share Pictogram” in the book that was used a lot but not in the intended way (e.g we lost the majority of users at the next screen.)
Explanation: when we re-open the app, we might have forgotten which book we were reading last time. We know that the cover displays by clicking on the share pictogram. Conclusion: we click and close the ShareBookView just after. Not to share anything, but to know the book’s title.
The button is not “accidentally” clickable. We wanted it to be so: to know wether or not the share button would be used (only) to see the book’s cover. This very action fills the need to know which book one is reading, but this is not what it has been conceived for. Today, we still need to work on the book’s metadata problem.
Where the ‘onboarding’ becomes a core feature
Once we had built the core functionality of the app, we have been confronted to new kinds of questions. Should we continue to iterate around new features, or should we consolidate the core value?
It is difficult to both hear what users ask for (see screenshot) and stay focused on our ambition to scale. We shipped the first version without any kind of guide nor tutorial. After the initial launch, our focus was to consolidate the app. It meant 1- think of onboarding, 2- highlight and improve existing features and 3- fix micro-bugs.
Where we make the user nervous
First we have implemented alerts with a single ‘Ok’ button below the alert. We sometimes add a very small ‘Cancel’ button. Some users complained because they felt forced to click ‘Ok’. They didn’t see the ‘Cancel’ during the flow. We now have modified all our pop-up alerts with a yes/no choice.
We use them a lot to highlight many functions in the app that we want to be sure to be seen. We think that if an alert has not been implemented on a specific action, the related Mixpanel metric is not entirely exploitable. The user is not a private eye. For each release we validate first that the combination of alerts doesn’t damage Read’s first experience.
Where we find a simplest solution
It seems obvious to users that you can Delete, Archive or Share the book by selecting it in the library. When you click, it opens the book. Users generally try two gestures to access the book options: 1- long press on cell and 2- swipe the cell. This user decision is unpredictable according to our tests. We finally choose the swipe but… we designed an haptic feedback for the long press. We thus guide the user to access the book’s options with no umpteenth alert.
Today we stop Read since we do not have the “right” user-base to pursue our vision. (We are happy to know that Read helps thousands of readers to enjoy reading ebooks on mobile though.)
We constantly thought about our next steps with Read. The path we had in mind was to focus on a utility-tool first, then on the commodity aspect, and lastly on building a true community. With our current user base, we can not prove that we validated the first-step (e.g lots of people will need an ePub reader in their pocket, soon) ; and nobody wants to invest in the ebook market after so many startups failed.
Still, we went to the Y Combinator finale to explain and defend Read. I guess that they are aware that Amazon has only started the disruption of the book market ; and they wanted to hear what we had in mind for its next steps. They didn’t fund us though. They valued the fact that we built a great user experience in their feedbacks, and that we solved a true pain for some users. But to face the Kindle Store seriously, it is like if we had targeted the wrong group of people first.
I selected five stars feedbacks but before, I would like you read some of our one star feedbacks, to show you how easy it is to collect “single star” comments.
- WearyMax (RU 1.22) *
Ciryllic fonts :-/
Does not shown cyrillic books…
- Андрей Пилотов (RU 1.1.4) *
While uploading book.
On the other side, listening closely our users is really rewarding:
- nitinthewiz (US 1.23) *****
One of the very best!
This is one of best reading apps out there. From every detail, such as the scrolling view and your notes, to the easy way to send feedback to the team and the team’s responsiveness, I have fallen in love with this app, and you should too!
- Brad L. (US 1.22) *****
Great reading app focused on the reading experience
This reading app just keeps getting better. Looking forward to landscape mode and integration with Spritz. Highly recommended!
- Pellenir (US 1.20) *****
Great optimization of margins
Unlike ibooks (that puts a tiny little poem-like structure in the center of the screen) this app utilizes the whole screen, I accounted for at least 30% more content on screen. Great job!!
- TheOfficialTaj (US 1.20) *****
Best EPub Reader Yet
I love Read. I have searched for readers for almost two years now, tested and, well, «tolerated» all of them. But Read? I love it. I doubt there is or is going to be a better mobile reader for a while. 11/10! Bravo!
- dnx in B. (DE 1.1.2) *****
So good it hurts
I loved Readmill (especially when, while reading «Hatching Twitter», Chris Messina jumped in and explained how hashtags came to Twitter). But Readmill’s dead. Now Read is here: clever, beautiful, connected (Dropbox, Evernote). And free. You should get it.
Want to see my other apps? Check out. Critics are truly welcome!