Textura Payment Management System - Communications Hub
Business problem
Textura Payment Management system was a robust payment management system built for large scale building engineering projects. There were several user types including the building project owner, the contractor, the architect and the subcontractors. Communication on payment, draws, invoicing, and other financial matters was imperative.
The problem
The current state of the communications needed improvements. The current state of the communications offered limited functionality for the users. Not only were individual emails and communications being sent, but there were also auto generated communications that were triggered from actions performed throughout the application. Users needed an easy way to find and view communications and ultimately dig deep into related records.
My roles
As the Principal User Experience designer, it was my role to work closely with SME’s, product managers, designers and developers. I used prior research, interviews and demonstration feedback to develop a design plan and test designs to ensure user satisfaction.
Constraints
One constraint was the location for the communication hub had to remain the same in this iteration. This meant finding a solution for filtering the list when a user was viewing a project specific communication compared to their global communication list. This was solved by adding a auto filter when a user entered the communications hub from a specific project.
Another constraint was the users indicated they would like to have more data points in the communications grid to help identify specific communications. We were able to accommodate this by adding more columns of important information. Since they also wanted to be able to view all of the information that was important to them we also allowed for a flexible grid with fixed leading columns combined with a column management panel allowing users to indicate what data was important for them.
We also had to determine which frameworks and libraries we were going to use. In doing this we did come across some tech gaps. One particular gap was the filters. The grid we were using did not allow the filters to display as they had been called out in the design system. To overcome this we worked on designing within the component parameters to have the UI and behavior consistent with other elements in the application.
Our target users
There were several different types of user categories. Since TPM was specific to the construction and engineering industry we had building owners, contractors, architects and subcontractors all using the same application.
Our goals
We wanted to create a communication hub that provided users with several ways to find and view previous communications whether they were sent individually or through automation. We also wanted to make sure users were able to dive deep by being able to easily navigate to related records from the hub itself. In addition to that we wanted to reduce the amount of noise that they received by providing them a way to opt out of communications that were not relevant to them or their role.
Success metrics
- Number of users using opt out to reduce noise.
- Number of clicks to related records.
- User of filters.
- Actions initiated from a communication.
End result or outcome
Through demonstrations our users were excited to see what was possible and how they would be able to save time and reduce frustration by refining their lists. They were also happy to learn that we were going to reduce navigation and click fatigue by linking related records to the communication itself.
The solution requirements
- Elevate common interactions to save time.
- Provide users more transparency to communications data points.
- Provide users with the ability to filter and refine large lists.
- Provide users a way to view all large lists by adding infinite scrolling..
- Improve record navigation by linking related records.
- Allow users to opt-out of irrelevant communication types
Testing process
The testing was conducted with a demonstration allowing our subject matter experts, product managers, developers and fellow designers to experience the functionality and flow. This provided me with information that was used to refine the designs.
Through our testing we were able to
- Determined users wanted to be able to see as many columns in the grid as they felt was necessary.
- They wanted to be able to opt-put by category and specific types of communications.
- They wanted a way to view the “type” of communication they were opting out of.
- Users wanted to be able to quickly sort their lists by relative dates.
Cross-functional cooperation
I worked with a diverse group of cross-functional teams that included designers, product managers, developers and subject matter experts. Oracle had an culture of design collaboration, open feedback and teamwork.
Problem-solving and people-centered approach
I wanted to create an area for each of our user types to be able to customize their own experience. Allowing for flexibility in how the communication hub was used from someone who is super active in the application to someone who may use it for draw invitations and disbursements. After taking a construction fundamentals course from LinkedIn Learning and interviewing our project managers and SME’s I was able to find a deeper understanding of our user type’s responsibilities.
My reflection
This was a large project that needed to accommodate several user types and roles. From large construction project owners to smaller subcontracting companies. The design solution was successful and provided uses with the ability to view communications in the style they preferred.
