Why Would You Put a Smart Speaker in a Library?
Smart speakers are gaining more ground outside of consumers’ homes. Now is a great time to experiment with more avenues and explore how voice experience design can improve our daily lives outside of the home. For this challenge I wanted to explore an area that may not be initially thought of as a good idea. And I found just that: Putting a smart speaker in a library. Many people were skeptical which was music to my ears. It was time to see how I could change their minds as well as challenge myself in seeing the validity of what that experience might be. This article will examine parts of my design process and challenges along the way.
How do I start?
User Research and Survey
Knowing that there would be many different perspectives on this proposal, I initially created a survey to test the waters and get feedback. I had already thought through some of the implications of a smart speaker in a library but I wanted to also peek into the minds of the users. In the survey I asked them several questions like:
- What are some positive things that would come out of placing a smart speaker in the library?
- What are some negative things you can see about placing a smart speaker in a library?
- What (if any) are your biggest pain points when visiting a library, and how do you think a smart speaker could or could not help to solve that problem?
I also proposed a few sample questions that a user might be able to ask the assistant and asked the survey participants to vote which ones they would seem as valid and potential use cases. Surprisingly the question that got the most votes was “Where can I find this item?” — the one question that, for humans, would imply them actually physically showing the visitor its location. Though that is the most common type of question for a library to get, I thought it was interesting that it got the most votes.
When answering the question “What are some negative things you can see about placing a smart speaker in a library?”, the most common response was that a smart speaker would disrupt the quietness of a library. I knew that would be an obvious problem but I had already thought of a solution for that too (I’ll tell more about that later in this article). Other problems were things that weren’t unique to the library experience, just problems using smart speakers in general. The reason to put a smart speaker in libraries started to seem more and more feasible.
The responses on the positive side of things was very interesting. Some of the responses included:
- It would free up the librarians to do other, more complicated tasks
- You would be able to search the database in a quicker and easier way
- You could ask the simple questions instead of trying to find a librarian
- The speaker could read a story to children
- It would help save the library money
I had thought of some of these reasons so it was nice to be validated in my thinking as well as getting more ideas. I had never even thought of the potential for a speaker to read a story to kids!
Research on the Current System
I also did a little research on my local library’s database. I wanted to see how the computer system would handle different search criteria and what type of information it stored. Was it really intuitive? Could I pull some inspiration from the current way people would search for an item? Or does the experience need to be redesigned as a whole?
Coming out of a couple hours of playing with the database, I was about ready to rip my hair out! Yes the database is a great area of information but getting to the right information is almost impossible. For example I entered a simple search criteria of “dinosaurs” and “nonfiction” for the type. Literally the fourth result was for an alcoholic drink cookbook. The only reason it came up as an option was because of its use of the phrase “as old as dinosaurs” somewhere in the description.
This may have been a mistake and I’m sure there are other, maybe better, databases out there. But this was for certain: There needs to be a more streamlined way for users to find simple information. The database has TONS of information. But does a user really need or even use all of that? No. They usually need the validation of the title/author, its availability status and a location. Simple as that. You can’t get a better example of Pareto’s Principle than that. If they need more information, then the database is still there. But when talking to library visitors, their most common needs are pretty simple. I just needed to take that 20% of the most used features of the database and turn it into a voice skill.
What the Skill Isn’t
I also spent some time at defining the boundaries of this voice skill. It was clear on what it could improve upon, but there also needed to be some barriers of what it wouldn’t do. First thing was first, it would not replace the librarians. We are nowhere close on having technology replace the quality of customer assistance provided by a real person. Sure we have technology that helps to automate processes but true customer service is best with human to human interaction. And as a positive note, having a voice skill for a library would hopefully free the librarians to help with those more complex situations. Their knowledge of the library would be better utilized instead of answering where the bathrooms are every hour.
This skill would also not replace the database. With how much information is stored in the library’s database, filtering through all of that would not be suitable for voice. Utilizing this voice skill would be for the simple, quick needs of the user. There is always the database or a librarian to help with more complex needs and requests.
To the drawing board! (or rather keyboard)
Writing Scripts
With my initial thoughts and research set, I started to design some sample scripts that I would then prototype and test. Knowing there would be a wide range of questions that you could potentially ask a smart speaker, I wanted my sample scripts to reflect that wide range as well. I narrowed down some key use cases that would cover the most ground:
- Searching for a book and asking it’s location
- Searching for a broad topic
- Searching for an item that requires more thorough filtering
- Requesting a book to be ordered after finding that it’s not carried in the library
- Finding that an item is out of stock
With these few scripts written out, I needed to improve them with some testing. This would help bring to light what areas needed to be improved. Using SaySpring, I turned a few of my initial scripts into basic prototypes.
Test Test Test
My test included 3 different paths for the user to take. For each participant, I gave them just a brief overview of the skill and what tasks they needed to complete. Then I sat and observed my scripts come to life.
Before the participant left I also asked them a few exit questions to get their feedback:
- How natural did the conversation feel?
- Were there any areas that didn’t make sense or that caused you confusion? If yes, what did you expect to happen?
- If an experience like this was implemented in your local library, would you use it and what type of tasks would you most likely use it for?
The testing went smoothly and I was able to gather some great feedback. Overall, my scripts were well-recieved.
“It felt very natural, especially with the follow up on the suggestions and other solutions to the problems. I didn’t even have a chance to ask for help. It knew what I was going to ask.”
“It felt really simple. I felt like I could ask it any question and it would know how to handle it. It may not be as intuitive as a real person but it would be a lot better than searching the database.”
Key Takeaways
I knew that I was on the right track with my scripts and I needed to add some features to make the experience even better. My main things to focus on were:
- Make the experience as intuitive as possible by incorporating follow-up information. For the areas that this type of information was included, it got great feedback. I need to find more ways of trying to predict what the user will ask next.
- Include visuals to give validation and confirmation to the user. With the user needing to come up to a stationary place to even use the smart speaker, it would be natural to also use a screen. I can assume that they won’t be across the room trying to use the skill. They will have to be right next to it.
- Maintain the simplicity of the current scripts. Don’t get too fancy with it. The simpler, the better.
Challenge 1: Improving Scripts
The first challenge came with incorporating the feedback from the test participants. I needed to adjust some of my scripts to feel more intuitive and natural.
My first example is when the user is looking for an item that is not currently available. Upon finding their item, the system should give relevant information and give the user potential solutions.
1st Iteration: It looks like we don’t have it currently available right now. The book should be back on our shelves on December 20th.
In this first try, the effort of the virtual assistant seemed very bland. It just gave the user the bad news and not much else.
2nd Iteration: It looks like someone has it checked out right now. But it should be back in 2 weeks on December 20th. One of our librarians can help you to put it on hold otherwise here are a few books related to this title.
This version implements the cooperative principle and Grice’s Maxim of Relevance a bit better. The assistant attempts to give relevant information. It offers solutions to the problem rather than just stating the problem.
3rd Iteration: It looks like someone has it checked out right now. But it should be back in 2 weeks on December 20th. One of our librarians can help you to put it on hold otherwise I can show you some other book related to this title.
Though similar to the 2nd iteration, this one utilizes the turn of the response in a more human-like way. Instead of automatically giving the user related items, it offers related items and then lets the user decide. When considering that a screen would also be showing this information, it doesn’t make sense to quickly change the screen to show related items if the user didn’t want to see them. Maybe the user needed to view that information for longer or write down the proposed due date.
In accordance with the cooperative principle, the assistant should only change the direction of the conversation when prompted. This would also help the user feel more in control. Finding the balance between intuitively giving the user information and just offering the information was a challenge. I wanted to anticipate their needs but without forcing them down a path they didn’t want to go down.
Challenge 2: How Would the Assistant “Think”?
Writing these scripts helped me to see just how interconnected many of these questions were. They had the potential to intertwine in different ways. I now needed to explore the flowchart of the “brain” of the skill. How would it think? How would it make decisions? Using Lucidchart I was able to explore these thoughts.
This first flowchart shows the complex decisions made on the back end to filter through the database and narrow down the search for the user. When a user is using the database, they can put in any number of filters, and get any number of results. But with voice, it is a little more challenging.
The user can’t see all that a database sees. They may only give a little information, and the assistant might need more in order to give relevant and accurate results. That’s what this flowchart is attempting to portray. It would have to decide if it needs more information to narrow down the results. And based on what type of item they are looking for, the assistant would have to ask the right follow-up questions.
Though this isn’t all inclusive, it does show how a voice skill would be more intuitive than a database alone. Though the assistant would be pulling all of its data from the database, it would hopefully be more intuitive in its filtering and more user-friendly in its delivery of the information.
Challenge 3: What Would it Look Like?
It is clear that placing the speaker in the middle of the room or in a high-traffic area would make no sense. Libraries are meant to be quiet, and peaceful. And the speaker should not ruin that atmosphere. So how would you solve the problem?
One solution would be to place the speakers out of the way of the higher traffic areas in almost a kiosk of sorts. The affordance of this design choice would mean that the user would have to be standing right next to the speaker to use it and hence be able to see the smart speaker screen as well.
To avoid the disruption of the silence, you could also utilize directional audio speakers. These speakers are commonly used in museums to allow visitors to listen to audio without disrupting others around them. Their design directs the sound to a pinpointed location so only those who are standing underneath the speaker can hear the audio.
Smart Speaker Screens
For many cases of voice skills, you can’t always assume that the user will be seeing a screen on their smart speaker device. They may be across the room, or doing something else at the given time. But when placing smart speakers in a library, the situation is a bit different.
Since the speaker would be placed in specific places, and with the utilization of directional audio speakers, the user would have to be standing near the device to use it, and thus would be able to see the screen. And as in my testing, having visuals to support the responses would greatly improve the experience. This gave me the chance to play with the visuals and system persona.
Meet Oswald
Playing with the idea of an owl, I was able to experiment what some typical screens would look like in different scenarios. Throughout this process I had to ask myself the questions “What would the user expect to see?”, “How can I utilize the visuals of a system persona to improve their experience?”, “How can I package the data pulled from the database in a clear and visually-pleasing way?”
Going further I challenged myself to translate one of my designed scripts completely into screens. The following image displays the details of how the screen would change with each turn of the conversation.
Initially, the assistant would welcome the user and offer some example prompts/requests. Tapering for novice or experienced users was not as much applicable since there would be no way to distinguish between those two users in a public place unless the user prompted it some way.
Upon the user’s request, the assistant would decide if there was a close enough match to their intent and display the result/results on the screen.
Once results are available, it would show on the bottom portion of the screen with the assistant’s most recent response still visible. With so much information possible on the screen the user could always refer back to the assistant’s speech bubble to see what next steps are applicable.
The information that was chosen to be on the screen was based on Pareto Principle as mentioned earlier. The screen real estate is limited so only the most relevant information would be necessary. In this example it shows the item’s basic information and on the right it shows the availability status and location.
Conclusion
Though this article just scratches the surface of what this idea has the potential to become, it did help me to understand voice experience better. It challenged me in thinking of all the implications of a voice skill — not just within the skill alone but the environment in which the skill would be used.
So why would you put a smart speaker in a library? Why wouldn’t you? It has the potential to free librarians up. It would be a much more streamlined way of utilizing the library’s database. It gives the visitors another way to engage with their library experience. And I think Oswald the owl is just too cute.
Want More?
Follow the links below to see other documentation throughout the process.
