Whether designers should prototype in HTML (and CSS and JavaScript) often depends on the specific situation and goals.
HTML can be a useful tool for prototyping because it allows designers to create realistic interactive and functional prototypes. Useful for gathering feedback from potential users and for identifying any potential problems or limitations. And unlike other approaches to prototyping, closer to what the end product will be. And the constraints of the medium.
It also allows designers to simulate as closely to a real experience as possible and as such elicit real frustrations and reactions. That also means that your users will blame themselves rather than your prototype.
This can be dangerous because it means people will hide frustration. But it’s also something HTML prototpyes can illustrate to a team observing real behaviour. That people will think they’re doing it wrong. And not raise issues.
However, it’s a good thing to observe to keep yourself and your teams honest. We may not always see or hear issues because we’ve seen that users blame themselves rather than our tool. With a bit of storytelling, this can be quite powerful tool.
But HTML may not always be the best choice. For example, if the prototype doesn’t need to be interactive or functional, using paper or a visual tool can be a faster and easier way to create a low-fidelity prototype. Additionally, if the prototype needs to be tested on a specific platform or device, using a tool that is specific to that platform or device may be more appropriate. I’ve seen lots of prototype testing of paper leaflets and similar with photos on a screen. A print out might be better in this case.
A designer might also not be able to use HTML. Which can slow down and inhibit getting prototypes made. If this is true, find a way to support your designers (or youself) to learn. But maybe don’t choose something extremely time pressured to use.
Similarly, sometimes using HTML or similar means the designer can inhibit themselves by what they’re capable of. Not what a skilled team is capable of. Here we’re limiting ourselves by our skills not the future possibilities.
Ultimately, the decision of whether to prototype in HTML will depend on the specific goals and requirements of a project or team, as well as the designer’s personal expertise. The key is to consider what you’re trying to achieve, and the best way to get there. And support designers to develop their craft so they have several different ways to prototype. Not just 1.
So, at duckworth.design our designers create prototpyes in code. When it’s the right choice. For designers who don’t code. We support them to develop that skillset.