Your audience is one of the most critical things to consider when beginning a new data visualization project. This has two parts: the first is from an editorial perspective (what is the audience's background knowledge of the topic at hand? What types of charts will the audience be able to recognize and properly read? How do these charts work within the broader contexts of this story and other work published?), while the second is technological (what platforms and devices will be used to consume this content?).
It's really important to tentatively sketch out any bespoke data visualization before you start writing code, and this can take many forms. On the one hand, it never hurts to figure out the rough shape of your data before committing to a particular visualization style. Frequently, I've been asked for pie charts with a few small outlier values highlighted, which totally doesn't work (the rest of the chart dwarfs the outliers). You don't necessarily need to get a pencil and paper out for this; pasting your data into Excel and playing with its default charts often helps at this stage, before committing the idea to code.
The second way you should sketch out your visualization is on a component or an interaction level. This is where understanding which devices your audience uses is important. If you have previous work out there, look at its analytics. To see what percentage of readers use a specific browser in Google Analytics, look under Audience > Technology. Pay attention to Audience > Mobile > Overview also, which will tell you what proportion of your audience comprises mobile and desktop. If you have no analytic data to work with (for instance, you're launching a new project), it's generally a smart bet to assume that half of your audience will be on mobile, and so you should design your project accordingly.
Developing for an array of screen resolutions is called responsive design, and there are two major workflows: mobile-first and desktop-first. Traditionally, designs are begun at desktop size and are then scaled down for mobile, but this often means that mobile support is an afterthought and it's often problematic shrinking down large elements later on. Mobile-first design starts at the smallest possible size and scales up, which is often easier as you get the more difficult versions of the page designed first and out of the way, and can let things grow as screen resolution increases.
Whether you need to do either depends on your audience--it's quite possible that it predominantly uses one platform or the other, reducing the need to accommodate both. Again, check your analytics. That said, while ensuring that things work well, cross-device and cross-browser take a lot of additional work it should be a standard of excellence that you strive towards as you create things for broader consumption.
If creating a mobile-first design, take out some paper and a black marker, and draw a bunch of phone-sized shapes. Draw squares where you want each user-interface element (buttons, drop-down boxes, radio buttons, and so on) or chart to go. How you distinguish each element from the others is entirely up to you just ensure that whatever vocabulary you use is shared by those you work with. You don't need to be super artistic with it; just be detailed enough to express how you think each user interaction (clicking/tapping, swiping, dragging, and so on) should feel within the project. Sketch out roughly how you think each element should flow on the different devices. Then, do the same for a larger desktop screen size:
If possible, run your pen-and-paper prototypes past a few people to see whether your user interactions feel natural.