Requirements

Project Background

With advances in mobile graphics and machine learning, lifelike augmented reality avatars are becoming feasible as an alternative to a human presence in customer-facing interactions. Whilst touchscreen check-in systems are often in use in receptions, these remove the social element that a human receptionist brings and lack identity, taking away the ‘face of the company' element that a human receptionist provides. The technology now exists for some of this reception functionality to be delivered by a virtual assistant. Using a simulated humanoid character in an augmented reality setting is an attempt to re-humanize this process and allows a company more control over the first impression that a visitor has when coming to a building.

Our original task was to create a receptionist for use at IBM Headquarters in London. We were told that it would ideally have functionality to provide information about the company and any events happening in the building, as well as being an impressive demonstration of what IBM technology could do. Additionally, as a stretch goal, we wanted to provide proof of concept avatars for other settings, like a library, museum or healthcare setting, to show that this was a technology that could potentially be used in other organizations apart from IBM.

We had to consider that our users could be anybody who walks into a building with a reception, and that Augmented Reality is a relatively new technology that many people have not seen before. It was therefore important to consult with a wide range of users and to make our project as user friendly as possible.

Project Goals

Our main goal was:

Use IBM technology and a game engine to provide an animated augmented reality avatar that is capable of responding to basic reception tasks.

Sub Goals

Our sub goals were:

Make the avatar as lifelike and user friendly as possible
Prove that the avatar could be adapted to different contexts and organisations
Make the project extendable and open source, so that others can build on our work
Find out what kind of ‘basic tasks’ are most likely to come up in a reception setting and build the avatar to be capable of responding to these tasks

Requirement Gathering

We knew that not many people have used AR before, and our team had never designed or built an AR experience. Therefore, we conducted initial user interviews to get insights into users’ goals and attitudes towards the idea of an AR receptionist in general. We interviewed two classmates, one who had not used AR before and one who had, to gauge how experience level might affect user’s goals and requirements for an AR.

Se Jin had used AR before but found it buggy and hard to use. He would be very curious about an AR receptionist and would want to talk to it, find out what it could do and push its boundaries. He would ask it to contact someone in the building and would also like to ask it questions about itself.

Eunice had never used AR before and felt she would prefer to interact with a human receptionist. She seemed unsure of how she would like to interact with the avatar. She would want to find out where to go, and also to ask questions about ID badges and access. She would like the AR to be as human-like as possible.

Following our interviews, we conducted a survey where we showed potential users some different types of avatar (realistic, cartoon, robot, humanoid, hologram etc.) to gather information about what kind of responses users might have to an AR avatar. This helped us form some more requirements about how the avatar should appear and what kind of qualities users are looking for in a receptionist.

Finally, we built several different prototypes which we tested with different users – see the HCI page for more detail. This helped us pin down the most important requirements - for example, it was at this stage that we decided the avatar needed to follow the user with its eyes or face, because otherwise the avatar appeared very static and it was hard for the user to engage with it.

Personas

When we did our user interviews, noticed that our interviewees had quite different attitudes to the AR, which were probably linked to their familiarity with and openness to new technology. We therefore encapsulated these requirements by creating two personas, differentiated by their level of experience using AR and their open-ness to new technology.

MoSCoW Requirements List

Must Have

Basic animated figure that appears situated in world space in an app on an Android phone
Takes voice input from user
Has text input as an alternative
Answers basic questions from the user, specific to IBM
Interfaces with a basic staff directory to provide room numbers and contact info for staff
Shows a simple map of the building when asked
Basic error recovery / user prompts (i.e. encouraging the user to move away, communicating that it doesn’t know the answer to a question)

Should Have

Basic ability to adapt the avatar chatbot engine to different organisations by providing API-like functionality to edit the chatbot’s recognised question and answers
Ability to adapt the chatbot engine to different organisations by providing functionality to edit a database of staff info and room location
Integrates with an text system to notify a staff member by text that someone is ready to see them
Displays more complex information about the organisation when asked
Able to give basic directions
Able to integrate with a basic calendar system to show information about events happening in the building
Text information adjusts size, rotation and position based on user
Floor Trigger image recognition
Avatar reacts to users position and follows with eyes/face

Could Have

User interface for non-technical users to edit the chatbot for their organisation
More complex and lifelike animation
iOS support
Tablet View
Long Tail question answering using Watson Discovery to add unusual answers
Map / Direction system which locates the user in the building and is able to show them their location on a map, as well as information about where they want to go
Collect and display basic analytics about how users are interacting with the AR
Basic sentiment analysis of the user’s input to adapt the conversation

Use Case Diagrams

Here we have provided a use case list for each type of receptionist and a more detailed description of three specific use cases. In the “Design” Section you can see our more detailed use case diagrams for each specific chatbot that we made. NB. our “administrator” use cases involve a technically capable user: our application does not at this point have a GUI for non-technical users to change the chatbot backend.