Astinus
Concept for a Library Management App

Keeping a small library at home / office can be complicated: creating group awareness of who has borrowed a specific book or magazine, what is it about, other reader's opinions, etc.

This concept's purpose is to define an easier way to allow groups of people to share and track any kind of publications.

Its vision is that Individuals can perform some of the functions of librarians by being aware of the library dynamics and other's needs; loaning, returning and commenting without a librarian role might be possible.

Process

Step 1
Braindump, writing all ideas in paper

Facts

• Began by annotating most of the things I had in my head, this would help me separate the facts & concepts by identifying which are obvious + redundant and which are relevant for the design problem.
• Writing out my vision and perceived facts helps me make new connections and ideas.
• Later, results are grouped in the 'Goals & Wishes' and 'Insights' lists.

Goals & Wishes, Insights

The goal here isn't quantity or quality, is exploration and discovery of possibilities:

• Feasible "corporate" goals.
• Key actors and roles in the product architecture.
• Possible key features in the product.
• Viable minimum marketable sellpoints.

Step 4
Service/User Journey Development

Decided to structure the insight in 4 time-based stages:

1. Emergency of needs: What takes place when readers have these needs? How these needs come to be? How can people relate to their needs?
2. Service engagement: What happens when they get in contact and still havn't used anything? How they came to this service? Have they showed interest? How did it manifested in actions?
3. Actual usage: How have people used the service? Are they using it as intended? Shortcuts? Have they taken any physical evidence with them?
4. Post usage: Were user needs fulfilled? Why/When/How? Why is the service not being used at this time? How can it be of further help?

And for each stage I came to think of:

• Facts: discovered insights in form of factual information.
• Challenges: opportunities that could be translated into interaction flows and features.
• Ideas: ideas for: features, new interactions, information patterns, touchpoints, etc.
• Frontstage: the 'human face' of the process, direct interaction with people.
• Artifacts: devices, documents, technology, furniture, etc. that allow interacting with the process and system.
• Backstage: processes that the Public Users do not directly perceive but have influence in their experience

Step 6
Core Features & prioritising with feature mapping

Feature Mapping

By analyzing the scenarios, journey matrix and concept diagrams, surfaced a general set features the service could have.

Each set goes from most essential to least essential, from basic functionalities to accesory delighters.

1. Musts: This is the core of the service's functionality, without any of these features the system doesn't work.
2. Nice to have: Things work and run without these, but there might be some inconveniences, perhaps perceived as rigidity.
3. Optionals: These makes the experience go better by being available in the right moment.
4. Interesting: Basic delighers, makes things feel nicer.
5. Differentiators: This is the awesomeness, aimed at delivering superior delight.

Separating each feature into sets allowed a clearer picture of how the solution should interact and also be developed.

The next step is specifying what is to be built, and in which order.

Step 8
Interaction Framework, Defining the interaction & basic architecture

Roles and Objects

Defined the User roles and Data objects to be used in the functional elements, not in software programming, but in Interaction design.

• User Roles: Functions that a person can assume when using the system.
• Data Objects: The things the users can create, manipulate, look for, etc.

This specifies the limits of what can be designed for, in form of discrete functions operated by a User Role on an Object.

Who, what, where & how...

For having a good grasp of what can be done when designing the functional interface elements I define these too:

• Functions per Role: Enumerates what can a Librarian user & a Reader user do.
• Functions per Object: Describes the actions that can be performed with Publications, Users and Loans.
• Data per Object: Specifies the information that belongs to Publications, to Users and to Loans.

Step 10
Interactive Prototypes + Wireflow for Reader users

Interactive Prototype 1

This is the first prototype, decided to draw everything in my iPad.

Created the sketches using Adobe Ideas and an Ozaki O!tool Stylus R.

Exported the drawings, cropped them in Photoshop and uploaded them to Dropbox, then made an interactive version with Marvel App, it worked amazingly well for a service in open beta.

Tested this first version with a couple of friends, which made a few complains and comments and proceeded to make them into the second version...

Wireflow

Interactive Prototype 2

The second version includes the previously gathered feedback.

Edited everything in Adobe Ideas and PS, but the interaction flow wasn't totally clear, so this wireflow helped me understand what was missing.

It was made in Omnigraffle, took around 1.5 hours of work.

Made changes to the main "Bookshelf", added confirmations, and a more clear interaction flow, it took around 2 hours of work.