I am an enthusiastic reader. I love physical books as objects; the crack of a spine, the texture of an embossed cover, the folded corners tracing progress through millions of words across decades of my life. I have books belonging to my grandmother, my father, my friends and strangers. Unfortunately the realities of living in a small flat in North London means I can only give up so much room to this passion. So what do you do when you have to clear out your library? While every book I own has brought me some form of joy, I know there are some I wouldn’t miss, others I would never read again.

Stage 1: Generative research, analysis and validation

I began with the following problem statement:

The problem I suspect is that while people enjoy owning books, they take up a lot of space and are rarely used after the first time they are read.

From this, I designed a simple research plan: find an audience of people who regularly read for pleasure, and conduct some interviews. My goals were as follows:

• Gain insight into the level of attachment people had to the physical objects themselves.

• Explore methods people use to discover new books and the amount they’re willing to spend on them.

• Investigate the reasons behind a preference for physical books over e-books.

I recruited six interviewees from a book club (one I was not part of, but subsequently joined). These interviews were conducted informally, and audio recorded with permission. The interviewees were excellent; I love taking to people about their hobbies as they tend to be very open and happy to share stories with you. Many of them overran the half-hour time limit, though I gained a lot of qualitative information in that time.

Processing this information was more challenging. I had plenty of great sound bites, a few real insights, but a lack of focus on my part meant I had a hard time turning all this data into something useful. To assist me with this, I used a process called Affinity Mapping. I wrote down all of the key points made by my interviewees, then grouped them by similarity. This helped me organise the information into key themes, which emerged as follows:

• Both lending and borrowing are really common among readers.

• Readers are nervous about who they lend to. More than just trusting them to bring the books back, there was a concern that the books wouldn’t be loved.

• Commutes are by far the most common time to read, though this may have been biased by my mostly working-age interview subjects.

• There seems to be a vibrant second-hand community.

• Readers are most likely to give books away to friends or to charity.

• Friends’ recommendations are the most highly valued.

Now I had some key themes to work with, I wanted to nail down a more detailed representation of my audience’s behaviours and needs. For this, I created a Spectrum of Variables, which allowed me to map my interviewees characteristics against a variety of metrics. I found this to be particularly fascinating as it surfaced details I would have otherwise missed, and I was able to highlight consistent trends across a wide range of behaviours.

As my next step was to create a realistic Persona, seeing these characteristics emerge one by one felt like my work was being done for me. The fewer leaps of faith I have to take, the happier I am, and this really clarified certain similarities within my interviewees. Looking at the image above, the two blue dots in particular (JT & MT) showed an uncanny similarity across every variable, and provided a strong case for a Persona. There was also some strong secondary correlation among the other interviewees, hinting at a slightly less proactive, but similarly passionate group of book fans.

For the purposes of this project, I decided to focus on the first grouping as my primary target. They already use technology to assist with their hobby (Goodreads primarily), they were the most enthusiastic about lending and borrowing, while also being the most precious about the condition and care of these books. There is something of a contradiction here; these people loved lending books, but were also most concerned about them being ruined. It will be a challenge to provide a solution that can handle both of these facets effectively.

 Alongside the creation of my persona, I was also doing a deep dive into competitive analysis. Initially I focussed on services to do with books such as Goodreads, PaperBackSwap, Little Free Trades and Amazon. This was quite a narrow scope however, so I widened my search to more laterally related apps, such as Craigslist and Jaspr Trades, who provide platforms to swap a wide range of items or services with other users. By performing a Plus and Delta analysis of these competitors, I was able to recognise the common trends and pitfalls, which should help inform the development of my own solution.

At the end of this stage of my project, I was able to summarise my research into a few key findings, both as a short-hand reference for myself, and as a quick way to keep my stakeholders informed of what I discovered over the past few weeks.

Key findings

• Borrowing is common amongst readers. There’s a vibrant second-hand book community to tap into. Donating to charity is more common than I expected, and people care surprisingly deeply about where their books end up. As a result, people are nervous about lending books, specifically whether they will get them back in a good condition.

• Commuter-reading is very popular. This may be biased due to my interviewee demographic, all of whom were London-based and of working age. A lack of free time was the number one reason why commuter-reading was so popular, and there was a pervasive sense of guilt over not reading more often.

• Recommendations from friends are the most valuable. Interviewees generally enjoyed both giving and receiving books as gifts. The success of Goodreads is a testament to the social potential of reading, though Amazon and other online marketplaces have devalued books as objects.

Stage 2: Feature prioritisation, product structure and project proposal

Equipped with a concise persona, a knowledge of competitors and a better understanding of the users, I needed to start moulding the project into a distinct shape. Without getting hung up on the details of the user interface, I wanted to decide on a list of features, and the structure of the app containing them.

The first step to fully defining the project was to list all the features I wanted to support, and prioritise them. This would enable me to focus on the most valuable features first, creating a Minimum Viable Product that would satisfy my users’ needs. To do this, I created a grid where I could score each feature based on user expectation, user impact, and build & maintenance cost. By weighting these differently, I could ensure a balance between what was useful to my users, and what was feasible to build. My persona was particularly useful here, as by thinking about what Grace wanted and needed, I could distil my findings from the interviews into something more tangible.

As shown above, it can be tough to balance features I love with the reality of their implementation. Scoring these required a fair amount of guesswork on my part, too; I’d have loved to bring on a tech expert to help me score build effort in particular.

Here were the features that hurt me the most to remove:

• Image recognition for book covers. This was particularly painful to remove - it seemed like such a cool, little quality of life feature that would end up saving users a lot of time in the long run. It was also something I thought would differentiate my app from others. The cost of implementing in particular was high though, and was not outweighed by users’ expectations.

• Tailored, algorithm-based book recommendations. Once again, I thought this was a forward-looking, modern feature that was a shame to remove. Though honestly my own personal lack of experience with any sort of AI-driven recommendation engine made this an optimistic goal; so on the chopping block it goes!

• Ability to pay for and print out postage labels directly from the app. This feature actually scored relatively highly (15/20). The reason I skipped this was two-fold - firstly I knew access to printers was limited within my chosen demographic, and as such it would have limited use despite its usefulness. Secondly, and more importantly, I felt as though sidestepping any payment systems, especially for my MVP, would be a big win in terms of both speed of implementation, and lowering the barrier of entry for users.

I now had a good grasp of my target users, their needs & requirements, a sense of my competitors offerings, and a prioritised list of features. The next step was to create a project proposal - this would become my bible moving forward, and a constant anchor against which I could weigh any future decisions. Below is an abridged version:

PROJECT PROPOSAL

What are my overall objectives?

• Deliver a stable platform of regular, cash-free book trades.

• Leverage the data from peoples’ self-created lists and activity within the app to provide actionable recommendations to the user.

• Build a responsible, friendly community around the service.

Who is my target audience?

• Young professionals

• High level readers

• City-dwellers and commuters

• Based on my primary persona, Grace

What features will I include?

• Manual book name input recognition

• Browsing based on popular/genre

• Book ‘profile’ with details and reviews

• Scoring system for ‘trade satisfaction'

• Ability to create and use user wish- and send-lists

• Chat interface between users who have traded/are trading

• Coin system as a virtual currency for trading. Users earn a coin for every book they send out. They can then spend coins to receive a book.

What constraints will I face?

• Initial adoption will require a big push to populate ecosystem with books

• People will have to cover their own postage & packaging

• Disparity of perceived ‘value’ of one book over another (for example, medical texbook vs short story collection)

• Rich data for books (reviews, ratings, ISBN, release year etc) and limited potential to scrape this from third-party sources

• System requires actions ‘outside’ of the app

• Platform has the potential to be abused by dishonest users

Having a list of features and a project proposal, I felt ready to start to form my app into a distinct shape. The first stage of this was to map out the key user actions my persona Grace was likely to need to perform. This was actually something of a challenge for me at the time, but can be summarised very concisely as such:

• Grace will need a way to list books she wants to give away

• She will also need to create a list of books she is willing to receive in exchange

• Grace will want to discover new material to read as part of forming the latter list

• She needs to track her progress, both in terms of books she is expecting to receive and books she needs to send out

• She will need to configure how far she is willing to deliver (i.e. Local only? Country-wide? Internationally?)

• Finally, she will need to be able to interact with other users on the app in order to achieve a successful trade

But what does this look like, in terms of the app? How will these systems interact with each other? And how do I make sure that features are where Grace expects them to be? For that, we’re gonna need to do some card sorting.

Card sorting is one of my favourite workshop activities to run. It’s simple to perform, hands-on and fun, and provides immediate, tangible feedback that is easy both for the researcher and the participants to understand. This session was no different, and before long I was able to quickly compare results and group my features up in a sensible and predictable way. From that, it was super straightforward to turn the data into a first version of the sitemap. This will inevitably change as we progress through testing, but I was comfortable with the general shape my app was taking.

Stage 3: Prototyping, Wireframing and Iteration

At this point I was already sketching out ideas - in the margins of notebooks, the corners of whiteboards - the app was starting to feel like a tangible thing. I had my features. I had my users. What I needed was an interface. I knew the only way I’d meet the deadline would be to work fast and smart - the more iterations I could test, the more feedback I’d get. I actually found this to be a totally joyful experience! Nerve-wracking too, but the regular feedback kept my mind focussed and my creative juices flowing.

For my first round of testing, I used pen and paper sketches. I’d never done testing like this, but there was something uniquely tactile about sitting beside someone and showing them these drawings. I only had eight pages, and the testing sessions ended up being a mix of testing the basic book-lending flow, and more general discussion around the feasibility of the format. My testees were particularly interested in how the ‘coin’ system would work - I think the ‘cash-less’ aspect, while born out of necessity, may end up being the most intriguing aspect of the app. Talk about a happy accident…

At this point I wanted to start formalising some of the fundamental layouts. The paper tests were an interesting experiment but I wasn’t getting the kind of meaty feedback that’d really help me improve. This required a switch to digital. Due to keeping the fidelity low, I was able to quickly update my sketches to something that suddenly felt less like a prototype and more like an app (despite definitely still being a prototype). As the designs improved, so did the quality of the user testing sessions. My scenarios could be more specific, and the participants had more opportunities to share useful insights.

I repeated this process a few more times. Each session provided me feedback, which I applied to my designs, while bumping up the fidelity and experimenting with the visual language of the app. Below you can see some of those steps, with a super brief summary of the feedback that led to the subsequent iteration.

Ultimately this was a very rewarding process; I think in total I went through six or seven iterations of my layout, structure and overall design. I actually had to revisit my sitemap and user flows; the feedback with one of the later iterations highlighted an issue with the navigation & discoverability of some features. This was a bit of a setback, and cost me a few days, but the effort was vindicated when the final round of testing proved these problems had been much reduced. It also gave me an opportunity to dig a little deeper with mapping out my user flows, which you can see a sample of below. I enjoyed taking this hybrid approach - as I already had mid-fi wireframes it was pretty straightforward to apply them to the flow diagram.

Prototype & conclusion

Thanks for sticking with us! This was the first project where I was able to fully implement the HCD process, and all in all I was very happy with the outcome. This project, completed in 2018, has formed the basis for much my work since, and while applying the process in a SaaS environment (especially one with a huge and lumbering featureset and codebase) is a whole different challenge, the ideals have remained the same.

Anyway; the moment you’ve been waiting for! Please enjoy this brief run-through of my Bibli prototype, which was built using InVision. I take no credit for the jazz.