Following a process, when others around you won’t follow any process, is extremely difficult. This is a problem that many in the field experience.
The key is to make sure YOU follow a process, and force others into fulfilling the duties that you know are necessary to do your job correctly.
For this project, I formally interviewed internal stakeholders, customers and led UX sessions to understand what were the most important issues to address before we even started down a monumental path.
I then met with our larger team and helped devise a site architecture and technology plan. We went through ideation rounds of wireframes and middle fidelity mocks, gathered feedback and solidified the UI.
I created our own EPRI Design System based on the Material Specification, wrote stories in JIRA, provided Functional Specification Documents, and performed quality assurance testing in various phases of the project.
The idea seemed simple; take two websites - one public and one private - and combine them into one. EPRI serves the public as well as their Member companies, and the disparity between the two sites was monumental.
We needed to figure out a way to show pages that weren’t public before to the public, but still protect sensitive information.
Once we had the idea, we had to then find out what was important to both our internal users and our customers: EPRI Members.
I interviewed over 50 internal users, which was way too many in my opinion, but allowed me to arrive at some common themes. I then led several small sessions with our Members to understand what their pinpoints were with our website. I then took those same questions and asked our EPRI staff what their opinions were.
From there I took the data and created a unified report to illustrate where the problem areas were and what the scope should be.
Sometimes this is the fun part. It can also be a point in the project that causes significant problems if the technology and requirements are not solidified.
As the Information Architect for this project, it was clear to me: there were so many areas where we could utilize components that it only made sense to work from a component level and re-use these components with specific configurations where necessary.
However, when you are working with several different stakeholders who have differing agendas, experience and understanding of UX, it makes the path forward unclear.
We went through several rounds of ideation, with different stakeholders, staff and management.
I first started with sketches on a whiteboard with notes. I then would take photos of those sketches and type up the notes. We would have meetings to discuss those, and as those were agreed upon, I would then refine those into wireframes and then eventually into mid fidelity mockups to get feedback, with the end result being high-fidelity designs for the Developers to build from. Those high-fidelity designs were created in Sketch and posted to InVision to utilize its Inspector tool.
As the situation stabilized and the restrictions became clear, we ultimately were able to solidify the requirements and then craft a solidified UI.
As we were finally moving ahead, we were able to create our mid-fidelity prototypes for testing. We opened up our environment internally first to a select set of users. One of the newer features we devised was a more sophisticated feedback component which we utilized to solicit feedback on a per-page level. We then were able to open it up to a subset of our customers for their feedback. Based on that feedback, we were able to hone some of our features and finish sections of the site incrementally.
It was a rocky road, and definitely not a process that I would recommend, but we arrived to the finish line eventually. It was a clear example of how an idea can only get you so far, and that a project has to have the technology and security requirements solidified before work can begin. It also was a case study of having too many stakeholders and a constantly moving target will result in a less than ideal experience.