Making the flip

A case study in UX product ownership and front-end development.

Part of a flow chart explaining how to handle the interaction between selecting parameters for a report and generating the report, while accounting for the types of errors that might occurs and when.

Challenge

The company's product, built in pieces over ten years, didn't have user experience as part of the product development cycle until shortly before I started working there. One of the first tasks undertaken by the new UX team was to modernize the thousands of pages of this application into a set of consistent interactions, buttons, visuals, and information architectures. The company was also under contract to become accessible, so all new UI designs had to have accessibility in mind. Each individual page of over 10,000 in the application would need to be manually "flipped" by a developer, and from a procedural standpoint the undertaking was monumental.

My Roles

Plan page flips prior to sprint so they go as smoothly as possible
Serve as a product owner in a scrum team during the sprint, providing UX vision to the developers and resolving impediments
Review finished pages during the sprint to ensure they are flipped correctly, and are fully accessible.
Design new solutions, pages, and workflows "on the fly" during the sprint, as needed

Supporting Material

Due to NDA and the nature of this project, there isn't one single file I can link to. Email mjennex@gmail.com for work samples. At the bottom of this page is a simple imaginary comparison for the system before and after redesign for a section I worked on that required more attention than most.

A search/filter submodule in the new UI.

Process

Planning the Flip

To prepare for the flipping process prior to the first sprint, we broke our system down into smaller and more manageable sections with similar functionality. Each of these sections could be tackled in 2-3 sprints. Before those sprints began, I would go through pages assigned to my team looking for anything problematic that might hold up the sprint, and produce any designs for anything that might be hard to flip.

Working with the Scrum Team

Once the sprint began, I would meet daily with a scrum team consisting of two backend developers, one frontend developer, and one QA tester. Each day we'd plan what pages from the backlog we would flip, and work out any outstanding issues. My purpose on this team was to provide the answer to any questions arising from confusion over how to apply the UX vision, and to clear any impediments so the team could keep moving.

Each day I would review newly flipped pages. I made a careful visual and code inspection of each page, and checked all functionality to make sure everything was working as intended. I would also have to run the page through a screen reader, verify tab indexes, and check all aria labels in the code for accessibility approval. If there were no problems, I would approve the page for release from a UX standpoint. For problematic pages, I would write up comments for the developers if the problems were simple enough, or I would discuss the issues with them during the following day's scrum meeting.

Designing as We Go

Often, the process would go smoothly. The scrum team would choose pages to flip, and I would inspect and approve them the next day. Sometimes the provided mocks or wireframes would prove unfeasible, such as the team being unable to implement the design within the sprint timeline. In these situations I would have to redesign pages or workflows entirely on the fly. This meant providing sketches, wireframes, and sometimes crude code mockups, on timelines ranging from a day down to just an hour.

With a project of this scope on a hard deadline, managing resources was very important, and design turnaround had to be extremely quick. I worked hard to craft a scrum team built on mutual respect. We worked through our problems to reach compromises that kept development on time without compromising the integrity of the user experience.

The project was an enormous drain of resources on the company, and our scrum team kept up this cycle for over six months before finally completing all the pages in our backlog.