Sr. UX Designer

PRODUCT SPACE
Trimble is a global company with many applications and tools in the construction and civil engineering space. The focus of this project is a feature in a collaboration tool called Trimble Connect. Inside Trimble Connect, many users of the construction industry such as Architects, Engineers, and Civil Contractors can collaborate in a digital space. They use a digital model that represents building data to compare that to the onsite objects being constructed.

PROBLEM SPACE
Creating an automated group using "rules" based on building model objects' properties.
A digital model of a building is a representation of what will be built in real life. Inside that model contains a lot of information about the objects that go into the construction of the building, ex: steel, pipes, type of concrete slabs, and many more. These objects have data attributes that show their properties. Object properties identify their materials, vendor origins, dimensions, and many more. People in the construction pipelines use these properties to organize their building workflow in many different scenarios. For this use case, we are focusing on the "delivery-status".
As a BIM ( Building Information Modeling) manager or project manager, at the office, I want to see the status of materials being delivered to my site. I want to see which vendor they are coming from and their status. In the past, this persona can search for these properties manually and group them into an organizer group and pass it to the onsite persona to check. However, the digital models of the building change often as it gets updated, forcing the user to have to go back into the previously created organizer group and manually re-link objects into the group. This process is cumbersome and is prone to human error, which could be cause delays and drive up costs for the construction project. 
The idea for the "automated group" inside the organizer is to avoid the manual linking of objects, but have the objects linked to a group based on a rule targeting their properties. This way, if the building information is changed or is updated, the group automatically updates without the persona having to coming in to relink. This would eliminate a lot of pain points and speed up the work process for our users.

BUSINESS INCENTIVES
If we can offer this feature to our customers, we can be competitive in the construction software industry. This is also a good opportunity to add colorization, a frequently requested feature, from our customer. Developing and launching an automatic organizer group with the capabilities to visualize progress via a color scheme will give our customers a useful and delightful feature.  

My Work

Process

Working with early requirements 
For this particular project, PMs have already gathered requirements through support tickets, clients, and stakeholders, but there were still unanswered questions. Often when I'm not involved in the discovery phase, I like to walk through the requirements with PM and ENG team. I map out early requirements to scenarios to understand the feature request in a more contextual way.
Another ambiguity of this project is that the requirements continue to change after each meeting we have our ENG team and partners. I typically approach this by trying to understand the key personas and the scenarios. Mapping this out with the team helps us have a common point when we discuss feature needs. After which it was time to narrow in on one scenario for early wireframes. ​

Early ideation

Identify a best case scenario to create features into wireframe to share
I map out early features into a workflow to a scenario and walk the team through it. We can use this low fidelity workflow to have many discussions about the technical feasibility as will as ideate on a different take of the features.

Low fidelity wireframes
Quickly mock up low-fi screens to tell the story based on user scenarios.

Mid fidelity updated wireframes
These workflows show features we have talked through with ENG and how they might look on screen with different variation of design so we can narrow down the best option together as a team.

---

Translating ideas into screens​

Updating wireframes to feedback and requirement changes
We have a lot of stakeholders that have weight-in on how this would look and function from PMs, partners, to support and engineering teams. We also have a lot of hypotheses about the core functionality that would be useful for MVP. Thus this is a very iterative process with lots of meetings and discussions. Some of the pain points are technical limitations, the desire to look like previous applications within the system, as well as managing lots of “asks” from various stakeholders. I offer many iterations on design and push for testing with our real users.

​Design iterations

Bringing Design into a higher fidelity ​
After getting the main workflow in a comprehensive prototype of mid-fidelity WF. It’s time to go back and bring it to higher fidelity to hand off to ENG. Here a design system is helpful to adhere because it’ll allow for product consistency. 

---

Value of user testings​

If we had not tested with users, we would have missed a major functionality requirement
Despite having experts and long-time stakeholders weigh-ins on the projects, no one brought up the need to load models. Without loading models, we couldn’t even begin the process of organizing the properties of objects. Our users immediately call this out to us in the testing session and it was a feature that we add in right away. 
For this reason, I work very hard to champion user testing with “real" end users not “proxy users” in the UX process. Furthermore, in user testing, we can put different ideas or designs in front of our users and help the team get a definitive feedback direction. The hi-lighted features below was added in based on user feedback.

More UI discussions 
The design process is not always linear as it is told. Often time, when I'm working on a feature there's a lot of back and forth talks with the product and ENG team. Here's a few design choices I would typically present the team for one feature. My opinion is that the toggle interaction is best for this instance because it allows for more space to show the objects on screen compare to the other interaction patterns.

Prototype click through 

Beyond MVP

While shipping MVP is important, we left a lot on the table ​
We achieved our object by shipping an MVP product with a list of features that is powerful and useful to our users. We test the prototype with 5 different client companies and confirmed that our MVP release would immediately satisfyied their needs. During this process, we also discovered that there are many "would like" to have features. I have captured those ideas here for a possible later phase beyond MVP. 

Add advance search with conditions in the results area
Add "tags" capabilities
Add a way to edit inside a data table