Mobile application design
This is my first project, all the steps were planned and executed by me. Although it is fictional, it gave me great opportunities to learn from my mistakes. So let me guide you through the process as it was actually done, and at the end I’ll highlight the most important “lessons learned”.
Bookful is application for borrowing / lending books, socializing and bringing people together based on their reading preferences.
Idea
The idea of Bookful app came to me when I was searching specific books on UX and graphic design as part of my learning process. Those books turned out to be expensive and not available in bookstores, only online, which added extra expenses on shipping. That’s when I got the thought – would be great if I could borrow it…
​
Research
I started my research from market and competitive analysis. After googling and searching in app store, I’ve chosen application Goodreads as my main competitor, and 4 other services (apps and webpages) that were worth analyzing. I’ve picked up the main advantages and disadvantages and put them into one table so it’s brief and easy to use.
The next step was user research (see “Lessons learned” section, point 1). Here is more about it.
​
To summarize it, user research results made me re-think the initial concept and shift focus from only borrowing/lending books to book based socializing.
​
The most important takeaways:
-
One of the reasons interviewees wouldn’t borrow book is that they would be afraid to forget to return it. This helped me to come up with idea how to influence it with the help of application features (setting reminders).
-
Interviewees would use the app to socialize more and get to know new people in different fields (“I’d like to get to know more people in my potential career field”, “I used to attend book club and loved to discuss read books”, “the app could be useful for getting recommendations for your next book to read”, “it would encourage me to read more”)
-
Demand for books in English is pretty high, especially in multicultural cities, though they are expensive and not many of them can be found in book stores (adds shipping cost)
​
How research impacted final design (key points):
-
The app combines borrowing/lending feature with socializing feature. The initial idea was just borrowing books, but during research I’ve discovered that with competitive apps users can socialize/discuss books or borrow them, but not both in one app, and people love to discuss books they’ve read.
-
The app allows to create groups with regular meet-ups. I got this idea when I’ve noticed that none of competitors encourage face to face meetings, but during user interviews it turned out they’d love to socialize live based on reading preferences
-
Bookful has rating system and feedbacks that helps to build trust between users.
-
The app sends reminders to return borrowed book - some users would be afraid to borrow books as they could forget to return it.
​
Personas and storyboards
After analyzing survey and interviews results I came up with 2 personas (see “Lessons learned” section, point 2):
Personas
​The next step was creating storyboards to visualize situations and scenarios of how and when people would use the app. Here is one of those:
Storyboard
​​
Sitemap
Once I’ve analyzed personas and the most important research findings I came up with 4 main application functions: borrowing/lending, socializing (messaging, posting updates, etc.), creating groups and providing feedbacks. Based on it I created simple sitemap, which at that point of the process looked like this:
Sitemap before
Many changes have been made after numerous testings, and, looking ahead, here’s the final sitemap:
Sitemap after
​​
Wireframes and testing
Based on application map I’ve created wireframes and made the first testing (see “Lessons learned” section, point 3). Before showing wireframes I explained concept of app and asked how would they expect it to look like. Once I showed wireframes, main questions were if wireframes meet their expectations, if everything is understandable, if they can easily point out main features, if something is missing or unnecessary.
​
How wireframe testing impacted final design (key points):
-
“Search friend” and “search group” options were added
-
Some of features were eliminated (like, creating photo albums)
-
App features were re-organized to avoid double navigation
Here’re examples of “before testing” and “after testing” wireframes:
Wireframes before and after testing
​​
Visual design concept and Low-fi prototype
Once I re-made wireframes and sitemap based on testing result, now it was time to come up with visual design concept.
Using Adobe Illustrator I’ve created two versions of lo-fi design for few main screens and conducted A/B testing (see example below). I was struggling to choose between locations of menu (at the top or at the bottom), so testers pointed out which they would prefer and why.
A/B testing
Once they’ve chosen better variant, I’ve created lo-fi prototype ( see “Lessons learned” section, point 4) in Justinmind prototype tool and again conducted testing, but this time to wider audience.
The main tasks of testing were:
1. To navigate through main menu
2. To search for a book and send borrowing request
3. To check details of a group you are member of
4. To add new book to a library
Also, I was interested how easily users can figure out what is the purpose of app, if the structure is understandable and what would users change.
​
How low-fi testing impacted final design (key points):
-
Menu was placed at the top of the screen
-
Less text on the screens, bigger letters
-
Menu icons were re-organized
-
User profile was re-arranged (feedback and main information are more outstanding
​
High-fi prototype and testing
Using Adobe Illustrator and Figma I’ve created Hi-Fi prototype and conducted testing (see images below).
Once again, I’ve asked users to complete few tasks. Like before, they had to search for a book and send borrowing request, review friends and group list, view profile and navigate through menu. This time I added few new testers, who’ve never saw or heard of this app before. For me it was important that design is tested with “fresh eyes”.
Also, worth to mention, that this time I’ve watched people testing design. It allowed me to see how people navigate, if they are confused, how long does it take to complete the task, also their impression.
​
Overall the results of the final testing were positive, but few important points were highlighted, like:
1. No clear distinguish between types of notifications
2. Personal info section is very limited
3. Some of buttons could be bit bigger
4. Menu icons could be bolder
​
Testing process
Final design
Lessons learned
​
1. Quantitative and qualitative surveys.
Once I’ve analyzed the results of quantitative survey, I could say it was not that useful as I expected. Simple Yes/No answers didn’t give me much of a useful insights, just a raw statistics. All the important information I got from qualitative survey. Only during face-to-face informal interviews I managed to find out motivations, pain points, preferences, fears or expectations of potential users. So if I had to do it all one more time, I’d focus more on qualitative survey - conduct twice deeper interviews to much larger audience.
2. Creating persona
Looking back at created personas I doubt their relevance to this particular project. Maybe if there was big team involved in the process it would be necessary to create personas to maintain empathy and make sure all of team members keep user’s needs in mind. But as it was just me alone, it would be more useful to invest time spent on personas in conducting more interviews with users and creating more detailed empathy maps, maybe better structuring it.
3. Testings
Testing was huge part of the project, I did it regularly, starting from testing the idea (while conducting user interviews), through process of creating wireframes, low-fi and high-fi prototypes. But due to many limitations I had to face (no budget, very limited time and social resources - I was on maternity leave), the quality of testings was not the best: not enough test users, similarity of test users, mostly remote testings. Also, worth to mention, I didn’t record results properly.
4. Creating prototypes
The process of creating prototypes was very inconsistent and took too much time. The reason is that I’ve created them in Illustrator first (I know, ignorantly skipped paper/pen stage!), then did the same in one prototyping tool ( to be able to test it), then once again in Illustrator and then i finally used Figma, which was the best option. Thanks to this painful experience I won’t make the same mistakes in my future projects and make sure prototyping process is consistent and efficient.