Designing Spares search solution for ERP

For over 60 years TransGrid has maintained one of Australia's largest electricity transmission networks to deliver innovative solutions to enable business. It is well placed to deliver smarter, more cost-effective grid connections for large-scale renewable energy generators.


TransGrid is a goal-oriented company with the complete agile development process as it has many integrated applications communicating to its ERP system. They had the plan to develop some custom projects to serve various business needs, which would be ultimately reporting back to the ERP system.


TransGrid planned the product "Spares" to manage its spare equipment in different substations in Australia. This product was challenged to be an independent application to simplify management of spares types of equipment separately from the ERP.



The project had kick-off with lean user research among the contractors, business stakeholders and technology provider. To get a better understanding of the field (and complicated electrical terminology), we conducted a contextual enquiry, ethnographic research, and several user tests onsite at TransGrid. We used their time to learn about electrical transmission, workflows, staff hierarchy, personal pain points, and the touchpoints process.


To make sense of everything we heard, we held a few sessions in which we categorised our insights in a few different ways. For clarity and to make sure we stayed on track throughout the process, we also mapped out midpoints to keep the business in a loop for each design solution approval. The problem statement was "How can contractors simply find the required equipment available around Australia?"


After validating our findings with the product owner, we used to focus on the scope, clarify requirements to the most in-depth details of acceptance criteria. Each sprint went through the ideation phase to tackle each business requirements. The user journey was technically designed to keep the implementation part ease. Then sprint planning sessions were done to decide on the features, user stories, and task analysis documented in TFS.


The sketches were drawn in the paper to outline the user journey and low-fidelity concepts for the solution design to discuss in a team. Other steps of design iteration were wireframing/prototype in AxureRP to document all the interactions and process flow to present in front of stakeholders and product owners. To efficiently explore conceptual directions and get quick feedback, the team decided to iterate and validated designs extensively throughout the project.


After the prototypes were ready for users to get an idea of the proposed solution. Design iteration in prototype allowed us to rapidly explore many directions early on without getting bogged down just yet by the potential implications. It also made it easier to frequently validate with the business to make sure we were addressing needs and designing efficiently.

User testing was performed to validate the business requirements and technical challenges to share information around multiple distributed systems. The prototype was an interaction guide for the stakeholders and developers to approve the solution. TransGrid is strict about it's budget, schedule and project deadline. The agile process was rapid to do iterations, validate and approve to go live.


The final output was the product design to search the equipment from any devices within the TransGrid network and book them through the request.

The product design principles were of Global Experience Language (GEL). The team had to define, create and maintain the visual components to be used in a finalised design solution to suit the business needs. That means, the proposed solution should be reliable to implement the proposition within the given budget. The visual components were similar to existing company products but used different shades of branding. However, we create many new components, so we challenged ourselves — every design decision we made considered the broader implications for the rest of the app.

Final Insights

Each product was distinct in terms of users, domain, design, and implementation. There were technical challenges in security, architecture, and solution design to deliver the business goals. Designing product on components approach helped development tremendously. Not only it allows us to iterate and get quick feedback rapidly, but also forced us to design efficiently across the different product.

Throughout every project design and development, we relied on our business requirements and extensive knowledge of domain experts. Ideally, we would have been able to get in front of more users or similar expert professionals, to get diverse perspectives and avoid bias.


Visual Design Components

This role had a huge involvement in design thinking for visual components as well. The entire TrandGrid component library was improved with new visual components and elements.