Opal Experience Reality

OpalXR is an experience based mobile application and web client that allows for people to create and access varying tours, memories, and collections published by themselves, other casual users, or official organization curators.

Time 6+ months

Team Four developers, one designer, one business manager, one technical manager

Problem Space

The initial drive for this project was from the geospatial software we were working with. We began with the idea of using location pinned data, and how to capitalize on that for the various stakeholders. The project ran through three key phases, with the core shifting with the clients.

First Phase:

Stakeholders Military Personnel, Police Officers, Citizens

My Role Visuals, Documentation, Use Cases, Proposals, Pitch Decks

Key Tools InDesign, Illustrator, Photoshop

Mule was focused on the idea of military planning and disaster tracking. Depending on who was using it, it could be used for mapping out routes, allowing citizens to document effects of disaster, or police to warn or notify people of issues in an area.

The project was still in the planning and proposal stages as it was pitched to different clients, allowing the developers to continue working on the mapping software while the project moved forward.

I was brought in at this point in the project to work on use cases, documentation, and proposal decks.

Second Phase:

Stakeholders Government Employees, Contractors

My Role Documentation, Use Cases, System Planning, Ideation, Visuals

Key Tools InDesign, Illustrator, Photoshop, Balsamiq

As the project started getting interest from new clients, the core shifted to location based collections. We focused on researchers and scientists, thinking about how different groups like the Army Corps of Engineers need to collect data and store paths and locations of research, and where different samples were tested or collected.

Trex would allow for people to curate collections and save them in a database to allow for data to be properly processed, as well as steps to be retraced as new data is collected to compare and make a proper analysis of changes in the same location.

Users would be able to log and store different media types, both locally on their device and on the cloud. Because of the goals of the application being used in the field, the idea was to have an offline mode where data packages could be curated before being uploaded when the application could reconnect and transfer the data.

Third Phase:

Stakeholders Tourists, City Inhabitants, Museums, City Officials

My Role Wireframes, Mockups, Use Cases, System Planning, Ideation, Visuals

Key Tools Sketch, Balsamiq, Illustrator

The project finally transformed into OpalXR (Opal Experience Reality). It still takes two forms, the web client for curation and the mobile application for capturing, sharing, and exploring experiences.

The first release will allow for two key roles, users and curators. Users will be able to access and view officially curated experiences, such as tours, restaurants, or social events via the mobile application. Curators can use the application and web client together to capture media and transform them into polished collections that they can publish and link to different locations throughout the city.

Later releases will enable social sharing, collaborative experience curation, and public experiences created and posted by users, as well as user created sub-experiences that branch off of previous or curated collections.

First Iteration

For the first iteration, I used the documentation provided by the managers and the working database from the developers to create a map centric app design. It didn't have a lot of flesh to it because we were still working out the details of the system, and trying to adapt them to our intended clients based on the information we were given from management. We worked with the constraint of limited time and information, trying to get a rough shell ready for the first round of feedback.

Although the app structure was feasible and it fit with the requirements we were given, it felt flat and didn't sit right with the team. After some deliberation with the business and technical managers, the project manager realized that we were approaching it from the wrong direction. We had been using the same data model from the beginning of the project, and trying to force it to work for the new direction. They decided to scrap parts of what had been worked on and I was given the go ahead to start from scratch on a new design.

Second Iteration

Although the app structure was feasible and it fit with the requirements we were given, it felt flat and didn't sit right with the team. After some deliberation with the business and technical managers, the project manager realized that we were approaching it from the wrong direction. We had been using the same data model from the beginning of the project, and trying to force it to work for the new direction. They decided to scrap parts of what had been worked on and I was given the go ahead to start from scratch on a new design.

System Map

I used the use cases I had worked on as a lens to start creating a map of the new system. I created a preliminary list of features and updated the list of use cases as new possibilities came to mind, and worked with the lead developer (who doubled as the project manager) to tweak and update the map and get approval for new potential features to be featured in the design.


After we had the general system locked down, I started working on wireframes in Balsamiq. I used the use cases to create different user flows. Using Balsamiq as a first step in the redesign was integral because I realized how much freedom wire framing gave me; I was able to iterate on the design quickly as I got feedback from the development team.

During this phase, we started working with a subject matter expert and had the new constraint of tours for our first push. This allowed me to narrow down the focus of the designs and work off of the new data we had to fine tune the features we had and propose new ones as we progressed.


I used Sketch to create the mockups of the application, and Adobe Illustrator to create the graphic components. All of the visuals, from wireframes to icons, were delegated to me as the designer. I enjoyed the balance of working on documentation and getting to flesh out the system while also getting to flex my creative and artistic muscles.

The subject matter expert we worked with provided materials for one of the city of Bloomington's walking tours, "A Walk Through Bloomington's African American History." I used this to help shape and direct the mockups, filling in the content to simulate what using the app might be like.

This version went through several iterations itself as new constraints were imposed. I was told to create the design in its fullest, to highlight all of the possible features, and then stripped parts of it down for the different releases. The initial release would include basic elements, with features such as favoriting algorithms and social sharing coming later.

While working on the application design, I also worked on the web client. It involved the same elements, but from the curator perspective. The constraints I worked with were the existing sites we already worked with, and needing to incorporate the current mapping software into the design. I used the sites as inspiration, tailoring the available tools to fit the project's needs.


This was an exciting project for me to work on, and different than the ones I had worked on previously at the company because it was the first product proposed and produced that we worked on which wasn't from an outside contract. The company is a small contracting company and we did a lot of government and military contracts around geospatial data, so this project was a big step and getting to be a part of it was great, but also difficult.

Because it was a small company, I was the only designer, UX or otherwise, at our site, and had to wear different hats depending on the day. Being the only designer gave me a lot of freedom, and a lot of responsibility. I thought it would be exciting to get to make all of the design decisions, but I also didn't realize how hard that could be. Brainstorming solo was a new process, and had a lot of pitfalls. I was trained enough to know not to trust every decision that popped into my head, and to make sure to be critical and thorough, but not trained enough to know how to make quick judgment calls and trust them. The project was a full learning experience, because there was no precedent at our company for some of what we were doing. I had to figure out how to shape deliverables for developers, how to communicate ideas thoroughly on the page and not just in meetings because

How to Shape Deliverables

There were no standards for how to deliver UX materials, so I had to figure out how to create documentation around designs to fully express meaning and give a full context. In school or shorter work projects, a simple design with a quick meeting is enough to communicate, but over a longer project there needs to be more tangible documentation for reference. We would all start on the same page, but as designs got handed off, and developers were working on different parts, the big picture got lost a couple times and interactions in the application became misconstrued. I had to learn to imbed text and notes into sketch or balsamiq files as to user flows and interactions. They didn't want something fancy and we had to work fast. They could care less about a slick InDesign layout, they just wanted something concrete and understandable in their hands.

Speaking the Languages of Developers and Managers

Everyone has a different vocabulary, and everyone interprets things differently. A lot of the language I use in school doesn't work in a small, tech-centric work space. I had to shift how I spoke depending on who I was communicating with. With the developers, they needed solid reasoning for design decisions to get on board, so I talked through databases and referenced attributes and relationships between elements in the design so they could see it in a context that worked for them. If I was talking to a business manager or one of the bosses, I had to speak more on customers and product releases. I had to learn how to communicate the same things in different ways, which makes your head spin but once I got comfortable with it made the work flow smoother.

Working with Little Structure

There was no contract for this, no customer I could talk to directly, the project itself was shapeless and continued to shift as we progressed. If there ever was a swamp in design, I was in the thick of it, and it was frustrating to no end at first. I had to learn how to prioritize, manage my own agendas, and communicate effectively. At times it felt like floating through the design space, tackling what I could and making room for sudden shifts in direction or new requirements. The first time I had to scrap an entire set of designs and start over was heartbreaking, but I had to learn to be open to change and be ready to drop what I had been working on or adapt it to the situation. It was a lesson in patience, time management, and flexibility.

Picking my Battles

Part of working in a constantly shifting design space is being able to change as needed, and I had to work at knowing when to let go of something and when to fight for it. Looking back, I realize that it became easier for me to let go of designs, or design elements; what I stood my ground with developers over tended to be features that were essential for use or consistency throughout the application. Part of that process was learning how to present a design argument and rationale quickly but carefully. Butting heads with a developer and getting into heated debates wasn't effective; learning how to explain it from a logical point that tied their section of work to the overarching picture and full application helped immensely. It was another lesson in patience, and openness. I had to balance being firm and standing by important points, but also being aware of the constraints of time and resources. Making a case for essential elements is great, but you have to be willing to make compromises. I learned how to make solid arguments, but also how to let go.