Open table
OVERVIEW
Open table is a mobile application designed to enable on-the-go collaboration of construction documents.
This was created as my first student project, the first plunge into UX design and an attempt to learn more about a problem I faced in the architectural design profession.
ROLE
UX Designer
Ideation, User Research, Visual design, Prototyping Testing, Pitching
Client
Self
Project duration
1 week
Background
As my first attempt at the UX process and a project since making the decision to move to digital design, I had decided to pick a problem that my past industry colleagues were facing given the rise of working from home - trying to draw and build a building through remote collaboration.
I found the architectural design process fit UX perfectly.
The outline of working in multidisciplinary teams through the creative process of site analysis, sketching, concept design, detailed design, tender documentation and construction delivery felt second nature to discovering, defining, developing and delivering of a UX project. During the short week timeframe, I had managed to refocus my human-centric architectural design thinking to achieve the following:
-
Successfully apply the double diamond. This helped me effectively work through the core stages of the UX design process, and recognise the many similarities from my five years in architecture
-
Trying on many different hats. Being a team of 1 gave me the opportunity to challenge myself in every aspect of design and research that was new to me.
-
Quickly and effectively upskilling. Working through an accelerated full design life cycle allowed me to gain new soft skills in user research and technical skills in figma quickly and effectively.
Understanding the problem
In my previous profession as an architect, I understood the pain of tools becoming a limiting factor and a point of failure in daily work. With the rise of remote working at the beginning of the pandemic, collaboration that usually happened in person faced new challenges and roadblocks.
I wanted to validate these problems with peers, so I ran small focus group sessions with 15 architects of varying experience levels who were all facing challenges working remotely.
“I can't just pick up a mouse like I can a pencil and do things”
“I lose so much time trying to work between different programs to finish one task”
“I want paper, pen and a table, but online”
After listening to these designers, I discovered the top frustrations:
-
Tools not fit for purpose. Architects felt constrained and frustrated attempting to make do with a number of existing non-purpose built software solutions they were familiar with to try and manage their work.
-
Time lost “travelling”. Going between multiple programs or apps made designers go through additional hoops and complicated workflows, making simple tasks take longer and more prone to mistakes.
-
Gaps in software knowledge. In addition to knowing the individual programs, it become important to know which programs could work with each other, or what file formats they accepted.
-
Lack of a streamlined workflow. Working with interdisciplinary teams meant different file formats were being used. Workflows quickly become over complicated and more technically challenging when files had to be processed prior to being worked on.
Gathering insights
To gain greater insight, I held 8 interviews over Zoom with architectural designers with work experience between 1 to 15 years to get a wider range of requirements and experiences. I carried out affinity mapping to group pain points under common needs in daily workflow.
Narrowing down the problem
To better prioritise my findings from the interviews, I organised the designers most common and pressing issues experienced across both management and graduate team member levels. I discovered:
-
60% of participants spent most of their time searching folders or email trails to locate mark ups they had completed.
-
50% had trouble identifying when a markup had been made and where it was saved or recorded.
-
70% stated trying to find the right tool for the task distracted them the task itself.
-
100% used multiple tools to accomplish, forming an unwanted secondary production pipeline prior to beginning design work
task tracking
simultaneous collaboration
document version tracking
file management challenges
communication issues
key:
managers
graduates
The architectural designers expressed the need for a simplified process:
-
Find the document I want, put it into the program.
-
Draw over it while discussing with my team.
-
Save off the mark ups for action.
-
Refer to what we’ve discussed in the past without hassle.
Archetypes
Based on my research, I recognised that there were 2 key user types that the solution would try to solve problems for. I needed to address the common challenges identified in the research in order to achieve successful collaboration. I decided to design for archetypes to keep an aspirational quality while keeping ideation open to interpretation.
Position: Architectural graduate
Role: Team member
Work Experience: 1+ years
Background
New to the field and eager to learn, the creator is quick to learn and deep in the production of documents and assets for the Conductor to review. They rely on the mark ups and annotations created by the Conductor to adjust their drawings. The Creator faces frustration when they struggle with complex problems, lack the experience to solve them and are unable to find mark ups to assist them.
Behaviours
-
Inexperienced
-
Inquisitive
-
Diligent
Needs
-
Clear and recorded instructions of tasks
-
Easy access to supporting documents for reference
Frustrations
-
Lacks experience to solve complex technical problems
-
Unable to find supporting documentation easily
Position: Project architect
Role: Manager
Work Experience: 5+ years
Background
Having years of experience under their belt, the conductor can recognise the best way to organise a project while they rely on the documentation produced by the creator archetype. They face frustration when they lose track of items, especially when they have so many projects to run and so little time.
Behaviours
-
Time poor
-
Meticulous
-
Planner
Needs
-
Clear and concise documentation
-
Consistent location of files
-
Easy task management for project team
Frustrations
-
Documents in different file formats
-
Information is in too many places
-
Tasks assigned are missed by team
Problem statement and product vision
After gathering the findings from the research, I worked on defining the problem statement to refocus my efforts.
Problem statement:
-
Building design professionals are frustrated with time lost on administrative tasks because of poor existing remote working solutions creating disconnected, unclear and difficult to track project documentation.
To gain more focus during the coming ideation phase, I wanted to create an intuitive design document management and collaboration platform with 3 key focus areas:
-
Make information easily accessible to the anyone in the project team. We want to team members to feel confident they have the right information by providing the ability to track document updates and key changes.
-
Speed up the project set up process to get teams working faster. We want to enable quick and easy collaboration by minimising time taken for tedious project administration before design work starts.
-
Make documentation and design collaboration seamless. We want to reduce time lost managing file formats and working between different programs by providing a single location for file collaboration.
Defining the MVP
Utilising the research and insights gained to identify the following key features:
-
Change tracking. Enable users to effectively document change history, users working on the document and the last person who modified it.
-
Project overview at a glance. Dashboard providing key information across multiple projects to team leads, allowing simplified tracking at a high level.
-
Virtual table space. View, mark up and drop in project documentation, notes and images easily accessible to the entire project team.
Designs
I began to sketch wireframes of the basic user journey to quickly test various layouts.
I quickly mocked up some basic wireframes to gather feedback from users on the overall layout, flow and structure. This involved establishing a standardised visual hierarchy and layout.
Validating the designs
I conducted usability testing sessions with our primary users to validate whether the new designs would solve their problems. I wrote a script including a scenario asking the user to start a new project with the required team members, add documents and annotate them. The usability session revealed:
-
Time from log in to starting arriving at a new workspace was too long (average 47 seconds across 5 users).
-
Being forced to enter all project details and team members created an initial barrier to starting informal mark ups. 80% of participants expressed this would be an end point for them and they would rather pick up a pen and paper.
-
100% of users disliked having to manually save a file - they would usually forget.
-
100% of users could not easily tell who or when they had been marked up by.
After gathering the insights, I revisited the prototype again.
Login page
A simple sign up page that allow users to either log in or create a new account using email, AppleID and Google.
Project Browser
The user flow to create a project was revised, the new table tile would no longer prompt for project details to be entered, rather a workspace would be created with details being able to entered anytime during working.
Table Space
The table space gave users a clear central workspace, simplified annotation tools and a collapsable change history drop down. Files and notes all stayed in the one space, providing a consolidated location for project work.
Results and learnings
I discovered the similarities that the double diamond process had with the architectural one, giving me more confidence to tackle the problems my users faced. The tight timeframe taught me a lot about being lean and knowing when and where to focus your energy and efforts.
Some key takeaways from this project are:
-
Focus on building an MVP. I only had so much time and effort to invest (especially when working full time!) so it was important to me to focus on the features that can delivered the highest value for users.
-
Don't worry too much about the detail. Earlier in the process, I made the mistake of worrying about the fidelity and detail of the UI. Taking a step back and reassessing the user flows helped me to reprioritise the UX.
-
Focus on the problem. Ultimately it is the users pains that I will be solving for, so keeping that front of mind is important as it's easy to lose sight of this when bogged down in the day to day.