I think the ideal scenario is having designers who code front-end. But the reality is most designers don’t. There are, however, more and more places where that’s the norm.
From the designer’s point of view, the designs serve primarily 3 main goals:
- Critique within team
- Test with users
- Discuss with clients
Paper sketches can’t be used for any of the above, even wireframes are hard to understand for clients and some users. Since every item has its purpose, sketching on paper (like sketching on a whiteboard) is best to facilitate a quick discussion about something minor or an idea, it can’t possible represent things like branding, look and feel.
Another place where it shines is portraying initial rough ideas to tweak quickly. There are things called paper prototyping, or cardboard models of products etc. They are often used to run through a scenario and get the sense of how it feels to use the product and if the vision has any big holes in it. It’s easy to miss important things when not acting it out.
Now, both hifi prototypes and straight html/css satisfy the points above. It just depends on the designer and the company internal processes. There is no rule stating hifi prototypes are a must.
What you use depends on what you need and project constrains. Need to communicate something that can be done by sketching on paper? Please do so, don’t waste time. Do it anytime at any point in the project. Need to test with users? clients only understand hifi stuff? Have designers living in html/css? Feel free to skip the photoshop/figma/sketch, etc. Have a client requesting exploring 2 very different avenues? costs less to iterate on prototyping tools? Then skip the html/css for a bit.
There is also this concept of fidelity. The more something looks like the final product, the more people believe they can’t give feedback and changes. They will hold back even if you tell them it’s ok to give. So a wireframe will naturally invite more than something that looks polished and finished. Showing a client a polished designed may not give you the feedback you seek for. But again, you could code a wireframe instead. Nobody is saying you can’t.