About a year ago, we embarked on an enormously challenging project: redesign all of our vendor productivity tools to be responsive, so that they would be accessible and more usable from any smartphone or tablet device. This would be a huge UX improvement for our vendors, who previously had no easy access to their accounts from mobile devices (and our vendors report spending around 30% of their work days away from their desks!). Also, moving to a responsive layout meant faster and more efficient development because only one codebase had to be maintained for all devices and screen sizes.
When the project began, our primary UX Designer created a folder named “Vendor Site Journey to Responsive Web Design" in InVision (our collaborative prototyping platform). At the time, I didn’t have the foresight to understand and appreciate how apt the name really was. Twelve months and 423 dev tasks later, it’s apparent this project was a journey for everyone involved. And that folder in InVision? It now holds over 500 mocks. It was also a challenging and atypical project from a product management perspective - and one that definitely deserves reflection.
As someone relatively new to the world of product management, I was just getting comfortable with the responsibilities of my job when I embarked on the journey to responsive design. I knew how to create a clickable wireframe prototype for a new feature and how to write detailed specifications for a product improvement - but this project didn’t require wireframes nor traditional specs, since most functionality was staying the same. I initially wasn’t sure what my role should be in this enormous project that was so taxing for both designers and developers, but I knew I needed to figure out a way to insert myself from a product management perspective.
For design, this meant taking screenshots of every screen/page and indicating the priority of on-screen elements so our UX Designer knew what needed to be included on all devices and what could be removed (or hidden) on small screens. Prioritizing on-screen elements up front saved a lot of back-and-forth with design, and it ensured that important functionality was prominent.
In this screenshot, you can see how I’ve indicated the most important actions on the page:
I didn’t create full wireframes for this project, but I did wireframe some specific sections of the site that were roadblocks for design. Not only is it a design challenge to fit a lot of functionality on small mobile-sized screens, but the on-screen elements must comply with standard responsive principles and use standard Bootstrap (our front-end framework) components. This meant a lot of discussion between designers and developers, and many design iterations from mocks to staging to production.
One of our most challenging pages for responsive design was the Event Details page, which has over 20 buttons/actions:
I quickly learned that it was impossible to predict with total certainty what the UI updates would look like on staging upon implementation. The style of specific on-screen elements was dependent on the Bootstrap components used on the page layouts. Some sections of the site looked very different from the mocks, which created a challenge for our QA Team when they began testing the updates on our staging environment. So that the QA Team could focus on testing functionality, I worked closely with our UX Designer to review each section of the site from a design perspective as each completed feature was deployed to staging. This resulted in numerous tweaks to the UI, but did inevitably create a more cohesive design across the site and a better experience for our vendors. Generally, our QA Team is responsible for validating the UI against the mocks and requirements, but given the size and scope of this initiative (and the many unknowns from a design perspective), stepping in during the testing period made a lot of sense for this project.
WeddingWire’s journey to responsive design was not a typical project from a product management perspective, but it was definitely a valuable one. Here are some important lessons I learned along the way:
- Prioritize. When building a mobile experience for your users, work closely with your designers so that everyone understands what functionality is most important from a business perspective and can design a mobile experience accordingly.
- Be flexible. Sometimes, technical limitations will make it hard (or impossible) for developers to implement UI updates exactly how they are depicted in mocks.
- Don’t become a roadblock. During implementation, respond to questions from your developers and QA engineers as quickly as possible.
- Figure out a way to help your team move a project along, even if it requires some non traditional tactics.