The projects showcased below span a period of more than two years working for a large multi-national company in the utilities (gas and electricity energy) sector with operations in both the UK and USA and over 10, 000 employees. While no two projects are ever the same I’ve chosen the ones below because they encompass much of an entire UX delivery lifecycle, from initial requirements definition, design and validation, through development and testing to deployment and support.
My role for the projects below was lead UX Architect. Each had their own challenges and problems:
- Project: 1 How to design an information system to replace an existing legacy system that managed the natural gas transmission and distribution network, serving 11 million homes and businesses throughout the UK, (with a fixed deadline).
- Project 2: How to design a new risk-based maintenance system for electricity transmission (England and Wales) that transmits electricity through about 4,500 miles of overhead and underground lines to distribution utilities serving more than 52 million people.
- Project: 3 How to create a proof-of-concept (POC) design for a replacement Intranet for 10,000+ employees in both the UK and USA.
Like many complex systems, there is often no agreed representation of the central problem is. This was the case for the projects listed above. This meant a lot of effort was required in problem structuring and definition as problem-solving.
In recognition of the need for both problem structuring and problem-solving three basic methods were used:
- Research – listen and learn as much as we could
- Satisficing – seek local optimal solutions that address most (if not all) needs rather than a spending extended effort in attempting to find a single unified solution that satisfied everything
- Pre-visualization – as soon as it was feasible, rapidly create testable prototypes (paper, wireframes, interactive mockups) and validate these using the findings to inform the requirements so that we could refine the designs and repeat the process. Steve Jobs often used a term called IKIWISI (I know it when I see it) to refer to something similar to this. It follows the “divergent”, “convergent” design thinking methodology.
Stakeholder Interviews, Heuristic Evaluations (of existing systems), Analytics (if available), Content Audits, Questionnaires, User Interviews, Ethnographic Studies, (especially important for control-room functionality).
Personas, Empathy Maps, User Narrative (stories e.g. “day-in-the-life of…”), User Journeys, Task Flows.
Lots of sketching, Ideation Workshops (“show and tell sessions”), storyboards, presentations (especially to stakeholders), information architecture, taxonomies including site maps.
Sketched concepts and wireframes, paper prototypes, low-fidelity and high-fidelity interactive prototypes containing realistic data and micro-interactions. Almost all prototypes were developed in Axure. Some wireframes were created in Powerpoint with a custom wireframe toolkit I developed specifically for Business Analysts so they could create basic wireframes without UX training, that were consistent, referenced standard UI widgets and page layouts (design patterns and style guide).
Heuristic evaluations, pre-sprint evaluations, prototype tests, A/B tests, usability and acceptance tests.
Refine and repeat
Not only in sprint retrospective meetings but for any pre-visualization produced at any stage we validated this with target users and their feedback used to inform, refine, approve or reject the proposed solution.