Graham Herrli's Portfolio

Process Improvement

Deliverables Redesign

A lot of my day-to-day work (and that of the other members of the UX team at AIR) is creating small wireframes and interaction specifications. I noticed that some people whom we expected to use the designs often overlooked them, so I set out to learn more about how we could format our designs better. I met individually with nearly 50 members of the development, quality assurance, product management, and documentation teams in order to

  1. learn about how they use our designs (and how the designs might be formatted better).
  2. make sure they knew where on the intranet to find key UX resources, such as the wireframes and the new style guide.
After the meetings, I put together a list of proposed changes to the deliverables, discussed them with the UX team, modified the results, and validated them with a larger cross-functional team. Then, I created a live demonstration of the new format, recorded a video walkthrough, and promoted it throughout the company. Largely as a result of this redesign, the company culture surrounding the UX team has changed drastically; we are now much more a part of the development workflow.

I can't share the video because it has proprietary information, but if you're interested, here is a PDF of the takeaways.

Broader Base of Stakeholders

Historically, the UX team at AIR has worked almost exclusively with the departments of product management and software development. I've opened communication with other departments. By attaching automation IDs to wireframe elements and communicating them to quality assurance and software engineers, I've enabled QA to write their automation tests synchronously with development. I've reached out to our documentation team to present wireframes of upcoming features, allowing them to provide wordsmithing input and helping them to understand what areas they need to research earlier in the process. I've started regular meetings with marketing to ensure that we apply the same branding to our software as to our other media. I've also held meetings with our business development and client services teams to re-envision how we can better structure our software to address our clients' needs.

Shown here (blurred to preserve confidentiality) is the product of a recent brainstorming session I coordinated with members of one of our client support teams. I used techniques from the book Gamestorming to have them generate questions they would like to ask the interface if they could speak to it and then to select the most important questions for further exploration.

Interface Review Meetings

To communicate better with members of product management and software development, I've established the practice of scheduling regular interface review meetings. Previously, features often were developed without any UX check-off along the way. Sometimes, product management would even create the designs themselves and pass them to developers to create before the UX team even heard about them. By scheduling regular meetings with product management and software development, I've been able to ensure {1} that the requirements are refined earlier to include usability principles and technical constraints and {2} that the UX team has an ongoing presence in the development process after the preliminary design.