Streamline data management for BWT
Data management within the BWT system is controlled by numerous departments of which each has its unique website. The departments require data sharing, yet the technologies are incompatible, which leads to a fragmented user experience. This is a problem as internal employees are unable to solve system errors and consumer enquiries with the disjointed systems.
The BWT data management system was composed of numerous websites written in various programming languages. Because of this, the websites could not simply be consolidated into one. Furthermore, the websites would not blend nicely with a unified UX/UI design and a direct integration would not benefit the users.
To further the problem, customers frequently requested new features, which often resulted in the construction of another website. Ultimately the overarching issue of the workflow was the lack of communication between the departments.
Discovery
I started my research with a competitive analysis in order to understand the UX of product management (PM) platforms and how they are approaching similar issues. This research method came to be a challenge as the data was known to be extremely sensitive information. To overcome this, I conducted one-on-one interviews with internal employees who had more expertise with PM systems. The interviews also revealed key points of user journeys and specific pain points the platform would need to address.

Personas were created to help gain clarity for the users, which would become crucial reference points for design decisions moving forward. As the research and design process progressed, I concentrated largely on two personas since they emphasised two key functions: customer service and product management. These personas helped me appreciate how wide a range I’d need to address.


Using the Agile approach, the Product Owner (PO) divided the project into small, consumable, increments. This benefited the team in providing value to users with the minimum viable product (MVP). The sprints allowed the team to set requirements, plan features and evaluate results on a bi-weekly basis. This structure served as a mechanism for promptly adapting to change.
In order to obtain an effective solution, the design process was extremely collaborative with the stakeholders. The set of choices in any design problem is almost infinite but through collaboration, we were able to balance the pros and cons of these choices: resulting in more considered features and overall better products. This process aided the team with a deeper understanding of the problem and therefore shared diverse perspectives towards the common goal.
Early on, I worked directly with the PO to spend time brainstorming and iterating on the product concept. Our goal was to validate the business case and ensure the engineering team's time was wisely spent fixing actual customer concerns.

After the initial planning and ideation, we would begin to engage with the development team. This stage provided the developers with just enough design (and code) to give valuable feedback on the solution.


Finally, the Jira story would be ready to work on in the following sprint after the adjustments requested from stakeholders. I always made myself available to support the developers if required.
At the start of this project, I experimented with rapid wireframe sketching, which allowed me to investigate design patterns and visualise how people might navigate between screens. This exercise was critical in determining which patterns could be applied to both defined Jira stories as well as future stories.

After the stakeholders agreed on the design pattern based on my sketches, I exclusively worked with mid-to-high fidelity prototypes. This decision was motivated by: the project's time constraints; how we could streamline the development handoff procedure, and how it made design decisions easier to communicate.

I worked hard to maintain a consistent design pattern so that the developers would not have to work on additional features. However, after a few months, user testing revealed that the design pattern for the tables (used throughout the website) was insufficient. Users found it unintuitive and difficult to expand the tables and make inline edits to the content. This caused a substantial delay in the project, but I overcame this challenge by creating a new draw style pattern within a few hours of receiving the report. The modified style was well received by the test users, and developers executed the style change.



