Bookworm – A library search mobile application

Bookworm was the web design project that Melissa, Joe, Cristal and I designed for Human Computer Interaction class. The other three are all very talented! Please check out their LinkedIn profile to find out more about them!

While each of us has some Graphic Design experience before, Bookworm is the first project that forces us to work together as a team, solve problems without teamwork and follow a specific human-centered design process required by the class (as opposed to turning on our usual solo heroic designer mode). The human-centered design aspect is fairly new to us. Instead of interpreting and creating our own solutions, we actually have to actively delay our own creative process, set out mind free of solutions from the very beginning and first try to come up with a worthy problem to solve (which turns out to be fairly challenging). Human-centered design also requires our team to regularly interact with our consumers along all steps of the process, which undoubtedly create many creative constraints on our end.

Teamwork can also contribute significant obstacles to a creative design project like this one. People will obviously not always be on the same page on all issues. We must learn to balance out different opinions so that each of us can creatively contribute to the project without putting too much strain on any individual’s capability and ego (obviously).

How do we take advantage of each individual strength without hurting the collective process. How do we harness each person’s creativity and how do we ensure a high level of innovation despite the regular constraints of our clients? Let me walk through the process of how we go through this creative journey from the beginning to the very end.

The problem with Agile process

If you happen to get involved in Software Engineering, it is very likely that you have heard of the Agile Methodology. Agile Methodology is a creative engineering process that involves rapidly iterating through versions of the products and release them to the customers to get their feedback quickly. The product after each iteration doesn’t have to be fully completed and perfect; it merely needs a workable versions of functionality that you desire feedback so that customers can quickly give comments on it before the product went too far. After each iteration, which is usually 2 weeks to a month, the process will repeat and address the bugs and customers’ feedback of the previous iteration and slowly one iteration after another, the process is completed.

You can easily get all kind of online resources about the advantage of this process compared to the traditional Waterfall process. What I want to talk about is the weakness of the process and why it might not be suited for product design. You see that product design suffers two problems. One is the increasing cost after each iteration. Product design shared this weakness with software engineering (or for that matter, all fields of product development) in which the product gets harder and more costly to change as it gets more and more complicated. It is, however, important to note that the increasing cost is much more drastic for product design compared to software engineering. The other weakness that is unique to product design is the diminishing return of effort. You see that once the overall design is fairly finished, there is very little thing you can do to drastically increase the quality of that design.

Because of these problems, the usually infinite Agile process has to be changed slightly to suit the unique nature of product design. It will still takes the iterative advantage of Agile, but not take forever (because after you design the product you eventually have to agree on the design and start building it) and will be fairly low in cost. Thus, we now have the four-step Agile process, which is uniquely tailored to suit the need of product design.

4-step Agile process

The process is now limited to only 4 steps lasting 2 months, each of which lasting 2 weeks. You can see these 4 steps in the diagram. You can also see the “divergence” and “convergence process” happening in each phase.

The first phase will be problem discovery, which will be focused solely on trying to find a good problem. No notion of a solution should be discussed at this point. The goal is to make sure that we find a good problem first. The team will “diverge” out and brainstorm ideas in the first weeks. After having a lot of ideas, team will talk with people to see if the problem is actually worth solving. After narrowing it down to only a few ideas, the team select the problem that it feels the most solvable or the most enthusiastic about, depending on the team criteria.

After figuring out the problem, team will diverge once again to figure out solutions. All ideas should be on the table at this point. After initial divergence, these scattered thoughts will be nailed down to a few ideas that can be sketched on paper. Using these papers, we can create low-fidelity prototypes and test on actual users. Users interact with prototype on paper.

After having some ideas about what makes a good solution and receives feedback for the first iteration, the team will try a higher level of fidelity. This time, the brainstorm process is less divergent (as you can see on the diagram) because the solution space is more limited. The second prototype should focus about solving problems that users encounter and report in the low-fidelity phase. The final achievement of this phase should be a medium fidelity prototype, usable on screen.

And there comes the high-fidelity prototype. This phase addresses feedback given in the second phase but mainly focuses on the look of the application. The final product is a high-fidelity prototype that is ready to go to production.

Discovering the problem

The first part of the project is to identify a correct problem that is actually worth solving. Our professor stresses the importance of this step emphatically. So often time ideas come out from a spark of innovation and inspiration, which is usually not well thought out and creates project that people don’t actually have a demand for.

We spread out and talk to many people at our school, as well as searching the internet to see if there is any problem worth solving. We completely let our natural instinct determines what annoys us in our lives and comes up with a list of problems. We decided to choose to improve the experience of our school library. In our school library, traditionally it takes these 9 steps to get the books that the students want.

1. Log on to Bucknell account
2. Search WorldCat for title or keyword 
3. Find an available book at Bertrand Library
4. Find the call number
5. Copying the call number to phone, piece of paper, or memorizing
6. Look up the online Floor Guide or find the physical copy
7. Finding the correct Floor, Section, Aisle, Shelf
8. Hope the book is actually there
9. Check out (maybe)

This is way too many steps to take the book and we believe that we can do better!

Low-fidelity prototype.

We initially sketch all the solutions that we think can think of. In this step of the process, ideas are more important than fidelity. We brainstorm out many ideas for the design our app. Things went along quite well in the beginning when all ideas are open on the table, but the situation starts to strain significantly when we have to work out what we should put in and what we shouldn’t.

We found out that often times, expressing the idea is much less important than expressing the purpose of that idea. Implementation can vary slightly from person to person, but as long as the purpose of the idea is insured then team members tend to be happy to go along. Since we are all designers, we always brainstorm ideas with well thought-out purpose in mind. In the end, we come up with a list of core purpose for the application:

1. It has to search books very fast.
2. The users should have an easy time seeing the books listed.
3. The users should be able to locate books very quickly without caring about the Dewey Decimals.

After agreeing on the ideas, we work together to produce a more well-polished sketch, which quickly transforms into a low-fidelity prototype as you can see below.

We print out the sketches and test these sketches with actual users and ask our users to naturally interact with our applications. We don’t give direct instructions such as: “Press this button and then that button.” We only ask general direction such as: “Find a book about Indiana Jones” and carefully observe the interaction to gather insights.

Turns out, there are four main problems with our prototypes.

1. The user wants to go to the map directly by selecting the book.
2. The users seem to care more about the location than filtering their own lists of books.
3. Some users want more context for the app. Such as, “You are on the first floor; go to the second floor.”
4. There should be more visual cues in the map.

Medium-fidelity prototype

Medium fidelity prototype focuses more on solving problems addressed in the paper prototype. We found out that most users struggle with the map the most, so we tried to address the feedback in this iteration. We try to make a very simple mobile prototype of the app with all the most basic elements in place such as interaction, shape and color. We actively resist applying arts into our medium-fidelity prototype, for the arts might look too nice for the users to criticize and give feedback to our apps. The medium prototype looks as below.

High-fidelity prototype

After receiving the feedback from the medium-prototype. Time to make the finished product. THis is the part that we are the most excited about, but also the part that is the most delicate to our team work. 3 out of 4 team members have design skills, so we have to be very careful in distributing work so that our specialities don’t overlap and conflicts don’t arise.

We found out that when working together, it is not necessary to discuss every single small decision points. When someone thinks that a tweak seems right, instead of asking for permission, they should just do it and ask for forgiveness later. That is because the best way to demonstrate an idea is the final product. In the end, the parts that require the most democracy from all parties are overall composition of the elements. When it comes to small details, dictatorship tends to work better.

To agree on an overall style and mood of the application, we uses an application called “Moodboard,” which helps users collect a series of image that best demonstrate the tones and moods of the application. Moods and feelings are the hardest to verbalize, but we find it astonishingly easy to describe them when there are accompanying images. We end up with a very teal, brown and bright look of our app, which looks fairly unorthodox compared to the more monotonous design. It works wonderful! And Melissa couldn’t have persuaded our team to follow this color scheme without the use of the Moodboard.

What we learn from the process.

The project is the first time we ever collaborate to design and we learns a tons about design teamwork. First of all, the user is king. Every decision we make for our app has to be grounded on user experience, and it is better to establish that mindset early on instead of waiting till the end. Designing with a team will bring significant constraints to individual productivity, so every member has to trust the team and be willing to give feedback in order for the team to functions. It is also better to have a bias for action. Instead of asking for permission, team members should just try to implement and then ask for forgiveness later. It is also beneficial not to be too strict on every single small decisions. Overall compositions and style should be discussed, but when it comes to minor details, dictatorship tends to work better.

This is the final design of our application. You can also try to use our high-fidelity prototype at this link.