Inefficient organization of site documentation slowed down architectural workflows.
In the office, I was able to directly observe how architects, drafters, and project mangers worked and interacted with site photo documentation. Not only did the school district see the value in the tool, but the team at Bartos Architecture quickly did as well.
- The team was constantly cross referencing photo documentation from sites with diagrams for various sorts of tasks.
- The photos were organized in complex, layered directories, with abbreviated file names.
- There was an opportunity for an elegant and intuitive design solution.
The design approach: "Build first, iterate later."
In order to demonstrate the value of our product concept to the client, we opted to build a simple, but fully functional prototype before allocating resources into the project.
With a collection of thousands of 360 degree photos that captured each room across 20 school sites, the primary goal was to build a online library that could be used to access and view these photos easily.
With the research findings in mind, I built a crude but working tool to display the panoramic facilities photos.
Though the process was chaotic, I fell in love with design during this stretch of the project. Every day, and often every hour came with a new problem to solve and bug to fix.
- I learned on the fly how to build sites in Webflow, the company's preferred web service.
- I drew on my knowledge of programming to add custom code for rendering the panoramic images in an interactive viewport.
- I managed a group of interns who helped me catalog the library of 10,000+ photos from across 20 school sites in the district.
“Wow, what app is this?” Prototype impresses at school district meeting.
This was the initial reaction from one of the district office directors when the lead architect pulled up site photos to reference in a weekly meeting. The owner my firm could proudly say it was a new tool they wanted to develop for the district.The tool's success and district approval paved the way for the development of the more polished version of the product.
Architects in our office became beta users, allowing for deeper research and rapid iteration.
As a designer, it was invaluable to be able to have users in our office. I leveraged my proximity to users to make quick changes, bug fixes, and collect data for further design changes.
With access to prototype users in the office, I was able to:
- Collect qualitative data through interviews with users.
- Recieve feedback in real time when users encountered a navigation issue or bug.
- Observe how the new workflows comparefdto prior office photo documentation systems.
Project Takeaway: Embracing constraints for greater for greater impact.
One of the most important lessons I learned during this project was that constraints—whether time, resources, or software limitations—don’t necessarily hinder a project.
The business factors at play didn't allow for a design phase with lengthy research or high fidelity wireframes prior to building the product.
Rather than spending time and resources designing a product that we didn't yet know the school district would utilize and appreciate, we showed proof of concept through a rough but functional prototype to sell the idea and develop further from there.
Though we "skipped steps" in a traditional UX workflow, this was a project that showed me typical workflows you're taught in classes don't always work in the real world, and innovations can be made in different contexts.
