In an ideal product world, responsiveness is considered at the onset of product development, especially if your core use cases justify it.
But for one reason or another, best practices get de-prioritized*.* It starts as something that "we can worry about later", and one day, the team realizes "oops, we can't put this off any longer", because otherwise, the business will suffer visibly.
A few years ago, my team was in such a situation. At the time, we had a web product of over 200 pages, and the team finally got around to consider responsiveness. The voices that pressured the team to go responsive were coming from everywhere:
I led the effort to build the strategy and roadmap , led execution and managed internal and external stakeholders , along with other moving parts. I will share some of my experiences and learnings on the way, and hope this helps anyone that faces same problems.
It's one thing to want to do something, it's another to get buy-in from others. Like in many companies, the team I worked on had to deal with multiple stakeholders, some of whom are non-technical. It's likely you too will face some resistance.
"This sounds difficult. We've never done it before! 🙀*"*
To ease this anxiety, I found 3 things helpful: (1) A prototype is worth a thousand words. It helps to give a quick "lunch & learn" to provide some foundational education to your audience. You can quickly make prototype that illustrate the idea. This might feel so obvious to people familiar with web technologies, but for outsiders, their eyes do light up when they see the "responsiveness" happening right in front of them with a few lines of code. (2) Show examples of well-done responsive apps. The bigger the name, and the more closely aligned to your products, the better. This helps pass on the idea that responsiveness isn't some fancy trick only hipster products do. (3) Lastly, share good learning resources on responsive web design. Google's RWD patterns (https://developers.google.com/web/fundamentals/design-and-ux/responsive/patterns) is a good starting point.
"But... won't this slow us down? 🐌*"*
Well, yes and no. You do need to consider the functionalities in different scenarios; you might need to be doing entirely 2 different sets of implementations for some work. But the hidden benefit of building for smaller screens (and often starting on smaller screens) is that it forces you to focus on the core of any tasks you want achieved by the design. With bigger screens, there's more room(figurative and literal) for "scope creep", but mobile pares things down to its essentials. It's a refreshing perspective. At the same time, the longer you wait to implement responsive, the more jarring the difference will be between different screen sizes due to design and technical debt, and the more time-consuming it would be to fix the Frankenstein.
Lastly, it always helps to show quotes and data to support your case. These can be videos from user testing, quotes from sales meetings with potential clients, industry analysis... anything that adds objectivity and urgency to your case.
Now it's time to put pen on paper. The roadmap shouldn't be treated as a static document. Rather, it's a reflection of aligned goals, which can adjust over time. To kickoff, we conducted a "product audit". Here are some questions to think about during the audit (adapted from Nielsen Norman Group's course on Information Architecture)
In terms of how to prioritize, there are many frameworks in the product world. We referenced the Kano model (Satisfiers / Dissatisfiers / Delighters), and did our own analysis regarding: