Introduction to my role and Builtview
BuiltView is a small start-up level software and company funded and run within Laing O'Rourke. Although the environment was quite like a start-up we were still subject to the bureaucracy of a multi-national corporation. This led to a major obstacles after my internship was extended. I was working in a small team of a Lead Developer, Software Engineer intern, and a Change Manager. I was originally hired for a summer internship (12 weeks) but was extended an additional 4 weeks (16 weeks total).
​
Builtview is a photo management application designed for construction teams. Builtview saves time for site engineers and creates a comprehensive record of site based photo evidence. This improves efficiency, preventing unnecessary site visits, solving disputes and saving money.
​
What BuiltView offers
-
Separate personal and work photos
-
Automatic cloud uploading between mobile and desktop
-
Customisable site reports
-
Organisation of site progression in Teams and Projects
-
Contextual photos with embedded timestamps, GPS location, tags, annotations, markups and more
-
Easy filtering of photos through tags, description, date, uploader or media type
​
Why was I hired? - Design Objectives
-
Prepare BuiltView for external use (at this point in time it was only used internally at Laing O'Rourke construction sites)
-
Evaluate the usability and improve user experience
​
These objectives are quite broad, and outside of general UX Research and UI Design, involves Product Design and UX Strategy. I worked alongside the Change Manager (who helps construction projects get set up to integrate Builtview in their construction processes) to align UX Strategy with the Product Strategy.
I was not given any formal proposal, instructions or guidance. This role was completely self-driven. I was not working directly underneath anyone and would discuss design decisions weekly with the development team. This meant a lot of freedom and learning through the internship experience. I struggled with many adversities resulting from limited onboarding, no design documentation, and missing data.
​​
What I Learnt:
-
How to communicate the value of UX Design to stakeholders
-
How to prepare and deliver work for the development stage
-
How to establish and integrate design system documentation
-
How to lead and justify design decisions whilst following stakeholder needs​
-
How to be adaptable and change design processes to meet time constraints and stakeholder needs
​
Let's Get Started!
Exploration of the problem area
With foundational primary research available for review, I started my design process by researching the construction industry and workflows to better understand the users and industry. Following this, a competitor analysis and heuristic evaluation was conducted to further evaluate and understand the product offerings and how to prepare the product for external use.
Analysis
Competitor Landscape
Using past data gathered in early stages of the development process for Builtview and new data gathered I consolidated a competitor landscape of similar products aimed at construction teams. This included looking at CompanyCam, GoTradie, Procore and much more. One notable competitor, UnearthLabs helped aid in UX Strategy in the development of effective onboarding, product tours and help centre content (available at support.builtview.com).
Competitor Analysis using metrics; Features, What we could adopt, What we do better, How the use cases differ.
Synthesis
User Personas and Empathy Mapping
Contextualizing the target audience's need for photo capturing and management for evidence-based site photo records formed personas which represented the different types of users which related to the hierarchy in the construction industry. In order to form these personas I organised a collaboration session alongside the lead developer. This collaboration session also lead to creating the structure of the questionnaire which lead users on different questioning based on the type of user they are.
Rough concept of the four different types of user personas; Solo Worker (Subcontractor), Team photo-taker (Site Engineer), Team manager (Project Manager), Photo Viewer (Design Managers)
Full Persona for 'Solo Worker (SubContrator)'
Empathy maps and questionnaires with sections based off participant personas were also developed. The questionnaire draft will be shown later when it is completed in a later stage of the design process.
Usability testing - Heuristic Evaluation
As foundational information from primary and secondary research has already been gathered and synthesised into user personas I needed to understand the product in its current state. The development team gathered some tasks to complete for both mobile and desktop in the heuristic evaluation. Another designer, Ana, also completed a expert heuristic evaluation on the mobile application. This testing session followed a usability testing protocol.​
​
Research Aim: Identify usability issues within the application through understanding the processes from the perspective of unfamiliar users (designers).
​
Goals: Usability Testing
-
Understand how users navigate, access features and use the application.
-
This will help us see why some features may not be used and issues with the UI / UX
-
-
Identify how new users would navigate the application to complete specific tasks.
-
Evaluate expert perceptions for potential improvements to the existing application.
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
Areas in need of improvement​
-
H1 = Visibility of system status: This mostly involves the visual communication of the user’s actions, such as when they have clicked on a button and active tabs as some examples. However, this also includes UX processes such as uploading content, internet connectivity and additional user confirmation.
-
H2 = Match between system and the real world: It is important to use symbols / icons / structures which are already familiar to users to increase the learnability of the application. The use of some icons (both mobile and desktop) are inconsistent with regular standards and therefore miscommunicate their functions.
-
H3 = User control and freedom: This heuristic focuses on the control of the user flow and the freedom of options given to users. This in general is very good for desktop by there are some ways to increase this through changing some button options and expanding on filtering options.
-
H4 = Consistency and Standards: Throughout the application there was limited consistency in the use of icons, pop-ups, placement of content, and following general UI/UX standards. This was also prevalent when comparing the desktop and mobile versions especially in style and use of icons.
-
H8 = Aesthetic and Minimalist style: Having a minimalist design is important for users to prevent them from being overwhelmed by options, this could mean removing buttons or changing icon buttons to text buttons.
​
Ana's results from her heuristic evaluation supported the results I gathered and added more data to support the results.
​
As noted above, there were many heuristic usability violations throughout the mobile and desktop application, causing a lot of user frustration. The application had persistent bugs and glitches, making users lose data and the application crashing. The desktop application in terms of usability was better but still needed improvements.
​
Summary
Despite the product offerings being quite simplistic, the user flow was often complex to complete simple tasks such as creating a new team. There were also many bugs, glitches and crashes noted in the heuristic evaluation which were communicated to the development team but did not relate to the design process.
The heuristic evaluation completed by myself and Ana allowed me to establish the objectives in the designing stage, which align to the heuristic evaluation usability metrics.
-
Improving the UI aesthetic
-
Establishing a design system for consistency
-
Improving user freedom and flow
-
Increasing visibility of system status through snack bars, dialogs and banners.
With a focus on user experience, some more specific goals for each interface were also created.
​
For Mobile:
-
Redesign gallery page structure
-
Redesign visibility of system status and error prevention (no internet pop-ups, success, errors, delete confirmations, etc...)
-
Experimentation of different user flows for photo capturing process (need user data to support this however)
​
For Desktop:
-
Collapsible side nav bar
-
Redesign for dashboard, organisation, teams and projects
-
Redesign visibility of system status and error prevention (no internet pop-ups, success, errors, delete confirmations, etc...)
Raw Heuristic Evaluation Data from Emily's ( me :D ) on the mobile application.
Architecture
User flows
Before beginning the sketching and wireframing of specific user flow and UX changes, I formed user flow diagrams for both the desktop and mobile application.
'No missing' Application - Irene​​
Features an application you can download which is designed to make it easier for more students to get involved in events through showing when and where all upcoming events are, users can share events, add to calendar and are notified.
Mobile User Flow in FigJam
Documenting all possibilities
Although the intentions of the application were quite single there are many possibilities. I noticed many errors within the application and each one needed to be documented clearly for both developers to fix and for me to re-design. As the UI was changing completely I needed to make sure I re-designed each page and each possibility.
​
Following the user flows as a guide, I took screenshots of light and dark mode variants of the current BuiltView application on mobile and desktop.
Mobile Screenshot of multiple possibilities and screens for reference
Design System Documentation
The design system documentation was in the works from the beginning of the design process, it was not till the end until it was consolidated, finalised and cleaned up. Dark and Light mode variants and various component states were documented in this design system. Results from user and usability testing further along the design process did not impact the design system.
​
You can see how the design system has been applied in the section below.
Interactive with the slide deck to see the design system
Slide deck gallery of 15 slides consisting of the design system documentation for Builtview
Designing
The designing stages of the project went through rapid ideation with sketching for particular sections, such as user flows changes for the camera page on mobile and the dashboard concept on desktop. Wireframing to mock-up was the process for UI based changes.
Some new ideas such as advanced tag management (with folders and archives), change to role functionality, notifications, activity logs, private media gallery and more were introduced in this design stage.
​
Although not shown here, all instances for snackbars, confirmation dialogs and banners were developed, to view these check out the Figma file.
​
Interactive with the slide deck to see some of the Mobile and Desktop mock-ups.
Builtview Mobile BEFORE
Builtview Mobile Mock-ups AFTER
Builtview Desktop BEFORE
Builtview Desktop Mock-ups AFETR
Research and Testing
User Research
Following the first iteration of the desktop and mobile interface, I conducted user research to evaluate the value of some UX changes and design proposals ideated in the designing stage of the project.
This round of user research was also used to support the overall objective of preparing Builtview for external use by gathering use cases and supportive statistics. Questionnaires and semi-structured interviews were conducted only due to time constraints.
​
Target Audience: User's who regularly use Builtview in their workflow and construction process.
​
Problem Statement: Understand potential threats impacting the integration of Built view due to limitations of the application or existing barriers within construction.
Goals: User Testing
-
Identify clear pain points for users and the reasons why.
-
Evaluate the most used and unused features.
-
Broadly understand user’s perspective on existing features.
-
Understand issues preventing further integration of the application in a project.
-
Identify the user’s perspective regarding the complexity of the application and reasons for not using particular features.
-
Evaluate recommendations from users to understand how best to improve user experience.
-
Identify the monetary value of using the application over regular processes.
​
Questionnaire Planning - Structure and Questions
Questionnaire​​
The questionnaires were structured in a way to lead users on particular questioning paths based on the type of user persona they were. This was because we wanted to find out more information regarding the needs of photo viewers to help re-design the dashboards and to justify some other design decisions.
​
Outside of this, some general data was gathered to support
overall Product Strategy and integration strategy such as, with
questions such as:
-
What features are you using?
-
Does your team use Builtview?
-
Does it save you time and money?
-
Does it improve your workflow?
-
Why or What do you like?
-
What deters you from using it?
​
​
Interviews
Interviews were conducted with two individuals, Beth and Alan. The interviews went on for around 25 minutes each and wanted to learn more about the experiences of Builtview users. The questions were quite open-ended in a non-structured interview environment. There was some pre-prepared questions regarding some concepts which planned to be introduced. ​
Questionnaire Planning - What are we trying to capture?
User Research Analysis
Affinity Diagram
Through a combination of quotes from the interviews and questionnaire an affinity diagram was formed. There was much more data gathered and given to the development team regarding specific bug fixes, however these were the main insights and changes resulting from the user research.
Affinity Diagram - Green = insights, Red = from Interviews, Yellow = from Questionnaires
Summary
-
Overall from the pool of participants from the survey (10) they are satisfied with BV and agree that it saves time, prevents unnecessary site visits, mitigate risk, saves money and improves efficiency.​
-
The main value of Builtview, which made it stand out from competition was the tagging feature, however if not managed properly there can be 100s of tags for each team. This slows down site visits as impacts the quality of record keeping.
-
Users will stop using BV and use their camera roll instead due to multiple bugs and glitches.
-
Users often forget to remove tags or team location before they start capturing, making it easy to lose photos.
-
Users were unaware of many new features and / or how to use them, suggesting features which have already been implemented and being discouraged to use new features as they don't know how.
​
Insights
-
The basic concept and features of BV has the highest value and therefore does not need to be more complicated (e.g. tags, photo categorisation / organisation, cloud saving, instant upload between mobile and desktop)
-
Outside of suggestions the only user frustrations came from BUGS and GLITCHES (particularly the mobile freeze)
-
For integration to be successful
-
Push and support from management or a ‘project champion’
-
Structure for implementation - especially with roles and permissions for easy use
-
Clear onboarding tutorial - the application can be confusing at first but is memorable
-
-
Users will use there phone camera instead of BV due to frustrations from it being too slow or bugs / glitches
​
What's changed?
-
Notifications concept was scraped and replaced with similar 'activity log' idea
-
Saving money preventing unnecessary development
-
-
Dashboard user activity monitoring on desktop scraped
-
Saving money preventing unnecessary development
-
- New plan to develop onboarding and new feature product tours and create new helpcentre content ​
- Resulting from users being unaware of features and / or how to use them​ - UX Strategy and Product Design
- BV Camera roll introduced on mobile to make it easier for users to quickly find recently captured media
- Improve error recovery from user based errors​
- Recently uploaded media and personal activity log added to profile page on mobile
- Improve error recovery from user based errors​
Usability Testing - Heuristic Evaluation
Usability testing was conducted on the mobile interface after the changes noted from the user research analysis have been implemented on the mobile interface. The testing will be conducted similarly as the first usability testing session so results can be compared and therefore prove that my design decisions have made a positive impact on user experience. A Heuristic evaluation was conducted by both myself and Ana.
​
The testing was conducted on TestFlight on apple devices, I tested version 4.0.0(304) and Ana tested version 4.0.0(306) - this resulted in some issues with Ana completing the test due to some specific issues present in version 4.0.0(306)
​
The results form my heuristic evaluation were minimal. A long 50 page document (available at bottom of page) was produced from the results I gathered which went further than the initial testing to document nearly all instances, both dark and light mode. To note, This was used as a reference point for the developers. Nearly all issues noted here were cosmetic (alignment, colouring, sizing and positioning).
​
Comparison of the Ana's first and second heuristic evaluation results.
-
Despite the second heuristic evaluation having more tasks (22 compared to 17) both the first and second heuristic evaluation noted the same amount of usability notes above a severity rating of 0 (being 8 issues total for both).
-
The severity of these issues in the second heuristci evaluation were much lower, with no major (3) severity issues noted compared to 4 in the first.
-
Most of the heuristic usability metrics were positive in the second whilst very few were positive in the first.
-
The tasks given to Ana in the second heuristic evaluation were designed based off version 304 and a basic understanding of the app which resulted in some of the minor (2) severity issues she noted.
-
All minor (2) severity issues were due to either bad wording of tasks or individual user errors.
Therefore, this comparison shows there has been a massive improvement to the usability and user experience for the mobile application. Resultingly, there were no changes based off Ana's answers in her heuristic evaluation.
Changes before final product
As mentioned above, there were a few changes to some new features and functionalities. In this section we will go over some changes which were resulting from the data above.​
Desktop
​
Tag Management
One of the more significant changes for desktop was with the 'tag' page in team settings. From user research it was clear there needed to be changes to make it easier for user's to create folders, allocate tags to folders and set up automatic geofence tagging. A new feature was also added to let user's archive and unarchive tags to make photo categorisation more efficient on construction sites during site visits with engineers.
Tag Management Mock-up Before (first iteration)
Tag Management Mock-up After (second iteration)
​
Creating Roles
Another change was seen in the process, default roles and options for role creation in Builtview. Beforehand, the options for each permission was vague and did not effectively describe what you were enabled or disabling. Default roles were also changed to 'Admin,' 'Member,' and 'View-Only.'
​
Other
Outside of the changes mentioned here, there were further changes to team and profile settings, and the dashboard which is similar to the mobile profile page.
New Role After (second iteration) - first iteration can be seen in 'designing'
Mobile
​
Profile page
It is clear that a persistent issue amongst user's is forgetting to change tags or location for media files before they start capturing again. This can make it very hard to track down the location of your media files unless you have a hard copy backup on your phone. Therefore the profile page was re-designed to include a 'recently uploaded media' slider list and 'activity log' which documents your uploads, edits and much more! This works alongside the new BV Camera roll which functions the same as a regular team, but only included captures you have taken instead of other members of your teams.​
​
The same design for the profile page on mobile was applied to the dashboard on desktop with the inclusion of recent teams.
New Profile Page
New BV Camera Roll
​
Camera page design
The camera page is the primary function of the mobile application, with the main intentions of Builtview is for capturing on mobile and managing or viewing on desktop. Hence, there are some limitations of mobile when it comes to managing teams. There were issues with the old design due to visibility of categorisation options, or tagging, descriptions and setting team location.
​
The changes also included improvements to visibility when uploading media items and option to pause uploads.
​
Other
Other changes to mobile include the display when editing information on existing media and the user flow for uploading
Camera Page Before
Camera Page After
Onboarding
​
The most important change resulting from user research was the introduction to onboarding and product tours. Although the application is quite simplistic, there are many other functions and features the app has to offer, such as automatic geotagging and floorplans. Users either did not know how to use it or did not know it existed.
​
Onboarding, product tours and new feature dialogs were all introduced for mobile and desktop interfaces. Unfortunately, only the mobile interface was able to have this integrated before the end of the project.
New Product Tour Dialog - Tag Management Intro
New Product Tour Dialog - Tag Management Step Three
New Product Tour Dialog - Profile Page Intro
New Product Tour Dialog - Profile Page 2
New Product Tour Dialog - Profile Page 3
Final Product Walkthrough
Unfortunately due to unforeseen issues internally at Laing O'Rourke, not all of the design decisions for the desktop interface were finished. This includes all the changes mentioned above for desktop.
The product is currently available internally at Laing O'Rourke due to sudden changes within the company regarding BuiltView. These will show me using the final application.
Desktop Final Product - recorded on app.builtview.com
Mobile Final Product - recorded on iPhone 14 on Builtview 4.0.0 (308)
Builtview Google Drive folder:
Coming soon!
​
Builtview Figma File