We created a mobile application that places an Augmented Reality world right in your workspace which you can mold according to your creative inclination through engaging interactions with other users to improve teamwork and collaboration.

My Role

This project was done as a three week design thinking and strategy effort. I worked alongside a researcher and a visual designer to see this project through and to ensure that it was completed on time. I was responsible for areas from the Design Strategy to the User Experience and Motion Prototyping.

Design Process

Since this was a fairly open-ended collaborative effort with no particular problem area in mind, we used iterative rounds of divergent thinking to materialize multiple problem statements which we could then work on. We believe that identifying the right problem space is crucial to developing a solid solution.

Identifying areas for design intervention

A quick round of brainstorming led us to four very strategic, but interesting, problem areas or goals.

  1. Facilitating discussion and not thought policing,
  2. Encouraging critical thinking,
  3. Building an ecosystem where potential is distributed,
  4. and, Creating value through collaboration.

A few hours of research later, we began by writing down the needs and challenges faced in realizing each of these four goals. This helped us define more tactical problems to tackle which would ultimately assist in realizing one of our initial goals.


This was followed by convergence through selection, where we chose some of the needs and challenges that we felt could be developed more. The selected problems were moved back to the drawing board where another level of divergent thinking was applied, and we branched out from each of the problems to arrive at a network of problem statements that were inexplicably linked to each other.

We used techniques like Brain Writing, Mind Mapping, and Flipping Assumptions to come up with a wider spectrum of problem statements that spanned wider areas.

Developing the Problem Statement

Each node in the resulting network map was discussed at length before deciding to vote on it so as to converge into a singular problem statement which can then be evaluated and developed further.


A few of the notable problems here that we wanted to solve were:

  1. Making children aware of local contextual problems
  2. Empowering people by attributing value to their knowledge
  3. Making data more approachable for everyone
  4. Creating discussions aimed at arriving at a common perspective, instead of a right answer
  5. Tracking participation of different parties in a discussion and moving towards a more balanced discussion
  6. Increasing classroom collaboration to enable everyone to have an equal say
  7. Familiarizing parents with the concept of experiential learning
  8. Developing empathy in children

After a few rounds of voting and discussion, we finally decided on the problem statement that we wanted to take forward.

How might we encourage critical thinking in children by increasing their awareness of local contextual problems?

Evaluating the Problem Statement

We further defined what the problem in the problem statement actually entails, and in the process, asked ourselves some very important questions which helped analyze its feasibility.


However, we felt that the problem statement was perhaps a bit too constrained, and solution-oriented in its current form. We did not want to deal with the solution at this stage. First, we wanted to define the problem in its entirety, and then ideate on the solutions after we are satisfied with what we are trying to solve.

The Abstraction Ladder

We mapped our problem statement on a scale from purely strategic to purely tactical. We asked ourselves why we are trying to solve what we are trying to solve, and how we are going to solve it. This gave us more abstract, as well as more specific problems, on either side of the Abstraction Ladder.

The ideal problem statement should lie in the middle. It should neither be too strategic nor be too tactical.


This revealed that the problem statement we had was a bit too much on the tactical side, and might lock us into very specific solutions. This was promptly solved by moving a step up the Abstraction Ladder and refining it into a broader problem statement which we would be able to work on freely.

How might we convert potential into value?


We used thinking tools to improve collaboration and to produce results faster during initial ideation. This was followed by plotting the solutions on a Difficulty-Importance matrix to narrow down on the best solution.


Refined Solution

After converging on a solution area, we started building on the solution.

A platform to enhance team building in office spaces using Augmented Reality Experiences

Secondary Research

  • Understanding teams
  • Team development
  • Characteristics of a good team
  • Team models
  • Importance of team building
  • Building an effective team
  • Success factors in team building
  • Effects of Augmented Reality Environments
  • Empathy through mixed reality

Primary Research

We needed to prepare data sheets, and accordingly, draft a discussion guide that researchers can use to collect data. The approach here was to get qualitative data that can be quantified and used in our design process.

photo photo

We went out with this discussion guide and collected some user research. The resulting data and the insights are in the detailed report linked below. With the primary research in hand, we proceeded to set down the scope.


Improving team mechanics and collaboration potential in workplaces by providing a common building platform in Augmented Reality where teamwork is essential and rewarded.


System Description

Problem Description: Teams that spend time building things together are more likely to be efficient when it comes to working together as well. The problem here is a lack of interaction aside from work in an office environment.

Solution Description: The solution is a platform which creates a world in the workplace that can be interacted with and modeled through interactions between team members. Interactions between team members can lead to permanent changes in how the Augmented Reality world looks and functions.

User Type: Team members are users in the platform as they start out with a basic element and then they can collaborate with other team members to build an inventory of items that can be added to the virtual Augmented Reality world.

Product & Technical Requirements

Functional Requirements: Platform - Native App Hardware - Mobile Features - Backend - Maintain an Augmented Reality world that supports appending the different blocks and elements that users may place spatially and mapping the spatial coordinates to a single source of truth.

Content Requirements: There needs to be a fair amount of user interface text to guide the users. This has to be placed in non-intrusive ways as to not interfere with the immersion of the user in the Augmented Reality space.

User Access Rules: Users gain access to different building materials through collaborations and they get to see their team members’ inventory to facilitate ease of collaboration.

Roles and Responsibilities:

Dependencies: Dependent on technologies like ARCore to facilitate the creation of the Augmented Reality space and to keep users updated in the building up of the space.

Language: Yes. Regionalising would help reach the target audience in more areas and perhaps even promote a wider range of users to participate in very different environments that are not necessarily corporate.

Scalability: The model is scalable to cover very large areas - perhaps even a single source of truth for spatial geometries across the entire world, which would open up unprecedented opportunities in collaboration.

Security: Team members’ information should be protected and would only be revealed after a member joins, or agrees to join a particular team.

Gameplay Design

Having the scope in place enabled us to focus on a Proof of Concept gameplay design. Game design was not the purpose of this collaborative effort, however, we needed something that works to show that the concept and the idea were solid.



Set of 4 unique elements which can combine as two, three and four. Elements are for the purpose of combination only and cannot be directly placed in the AR space. The combination of Elements creates Blocks which can be then placed in the AR space.


These are created by the combination of Elements. Element A (Player 1) + Element B (Player 2) = 2 AB Blocks (one goes in Player 1’s inventory and one goes in Player 2’s inventory) Once created by combining primary elements, the secondary element appears in the Players’ inventory. These elements can now be placed in the AR space to build things.

Elements are abstract. They combine in many ways to form various Blocks. Blocks can be placed in the Landscape however the user wishes to.

Combining the elements

Each player chooses 1 of the 7 combinations possible with his/her element. There could be areas in the office called combinational areas where the different members could come together to combine their elements, the socializing hotspots, like the coffee machine, forcing them to interact with each other while combining their elements.


The primary elements are thrown at the same spot in the virtual reality, at the same time, by the players who decided to combine their elements, which lead them to combine to give a secondary element which comes into the Players’ inventory, the ones who combined their primary elements. Building things

Certain guidelines would be provided to build things using secondary elements. Goals would provide an incentive to build things while not completely constraining them at the same time.

Information Architecture

The information architecture defined how data was connected and worked as a base for navigation, and further ahead, the sitemap for our wireframe. It was important that we take inputs from the user at this stage as well to optimize results and to ensure that this remains a user-centric product.

Card Sorting user study


Upon analysis of the card sorting user study that we had conducted, we came up with an updated information architecture and navigation map of the application. We used this as a framework to draw up quick wireframes for the screens to do a series of testing with the paper prototypes before moving on to correct some issues and push for an interactive wireframe with which we can conduct thorough user testing before moving on to the surface design. This step proved crucial in our workflow as it revealed a lot of insights that we used to streamline the product and the process that we were following.



We sketched out multiple iterations of pen and paper wireframes and multiple variations of user flows, which we then narrowed down with a few quick rounds of A/B testing.


This was refined and digitalized to create interactive prototypes which we could then use for much more detailed user testing and insights.


Low Fidelity Interactive prototype

The interactive wireframe prototype relied on a very non-linear workflow and had quite a few interface elements through which different navigation trees could be accessed. While this may not seem like the best idea, it was the direction that our research and card sorting results had pointed towards and we stuck to it.


The UI included a button to access the menu - which had three tabs to it - “Goals”, “Notifications”, and “Profile”. The elements, inventory, and the feature of finding other users or team members that had other elements were stashed away inside the elements dashboard at the bottom of the Augmented Reality live view screen, which was also the starting home screen. We also had a camera shutter icon and a switch to front camera button to enable taking pictures in order to introduce a social media aspect to the whole activity.

Usability Testing

Our user set consisted of users of different age groups and experience - therefore we conducted testing primarily based on four different tasks with varying levels of difficulty in the current interface to gauge the effectiveness of different flows. The detailed testing data for each user and the specific insights are enclosed in the full report linked below this article.

On conducting detailed usability testing with the interactive wireframes, we got some useful insights which were worked into progressive iterations with the wireframes and tested again.

After reaching a satisfactory level of testing, we moved on to testing motion interactions with a higher fidelity prototype that included swipe gestures and other modes of navigation - while we worked on to integrating the insights that we got from the interactive wireframe testing into the surface that was in the pipeline.


A few notable changes like rewiring the navigation to be more responsive and natural by changing the conventional menu solution to having tabs in the live view itself, and thereby reducing one level of interaction, and clearly separating the user’s basic element and the inventory was made. This was put through another round of testing.

As a result of testing this prototype, we figured that this model for navigation works - however some gameplay elements were missing. The Notifications section was rather unnecessary since we already had native device push notifications.

However, one element that was lacking was the ability to communicate - there was no way in which intra-team communication was facilitated. There was no way to set a meeting time or place in case two or more users were planning to collaborate and work on building objects.

Issues and refinements

One issue that popped up was the lack of an onboarding experience that takes the user through the game mechanics and how the concept works.

This was addressed in the next iteration by providing four beautifully designed informative illustrations that visualize the concept and generate a mental model for the effective use of the game for team building.

A tour of the interface and how the Augmented Reality trigger works is also demonstrated for first-time users of the app. This is achieved through a series of text annotations throughout the interface.

The best way to solve the communication problem, as we found through usability testing of the second prototype was by replacing the notifications screen with a team interface where every team member was listed along with the contents of their inventory and an option to initiate a chat session with them.

The chat session paves the way to interactions outside the medium of the app - as it should. It makes it easier to request for elements and then once accepted uses an NFC tap to initiate the process of element combination. This NFC tap works by tapping the phones of the two users together as illustrated. This ensures interaction in the physical world between team members.

Interactive prototype

The interactive prototype was built keeping in mind the results we received from the usability testing of the wireframes as well as the feedback we received by different people on refining.

photo photo photo


A huge shout-out to Anu, Ranjan, Vivek, Amruta, Surbhi, Varun, Rashi, Adarsh, Subha, Karunya, and Rishabh for their time and effort in user research and usability analysis of the multiple prototypes.