I need to show a client how customers will interact with the site. Should I bother prototyping in craft?
I agree with Dan's comment (i.e., use whatever medium will help you demonstrate effectively to the stakeholders), and would add the following thoughts:
The utility of prototyping does not lie solely in demonstrating a design to clients, but communication is a huge part of why it's useful. When I say "stakeholders" above, I'm including product managers, engineers, other designers, perhaps your marketing team -- anyone who has input into the final product.
It's also a must if you plan to do any usability testing, either in person or with a tool like usertesting.com. What you're after with these sorts of tests (and I'm talking specifically about product design here, which is not quite the same as marketing design) are reactions, not feedback. To get reactions, you need the design to behave as much like the finished product as possible.
I'm going to sound a little dogmatic, but I firmly believe that prototyping will make you a better, more thorough designer. As you prototype a design, you will be constantly previewing it to make sure the prototype is doing what you want it to do. And when you're doing that, part of your brain is thinking more like a user. You'll want to make everything work the way it should. You'll uncover use cases you didn't think about before. You'll discover where error messages should go. You'll find that some of the actions you wanted to have on the page don't make any sense. Etc. My only warning would be not to get carried away! Obsessive Prototyping Disorder can strike even seasoned designers without warning.
Do be mindful about using the right tool for the job. In my experience, static pages of content are fine to do in a static tool like Sketch. Prototyping is an especially useful tool when you have complicated flows and interactions that users will have to go through to accomplish some task. Since you asked specifically about Craft, I assume you're comfortable with Sketch already. I personally haven't used it yet, but if you find it's something you can wade into with relative ease, that would be a good tool you should use. You may find at some point that you need something more powerful for demonstrating more complex interactions. There will be a learning curve, but it'll be worth it.
[...] Or go straight to HTML/CSS?
I'll reiterate the importance of considering the right tool for the job here. HTML and CSS are generally good to have in your toolbox, but I often find that when I code, I spend far too long in the weeds, not enough time actually considering the design holistically. On top of that, a lot of interactions need to be added onto the static HTML/CSS document with JavaScript. What I've started to notice is that the more time I spend coding something, the more I begin to think like a coder. The allure of solving a problem in a technically easy or elegant way sometimes begins to overshadow the need to solve it in a way that works better for the user. There's an interesting phenomenon called linguistic relativity which I suspect is at work here. So my preference is to stick with prototyping tools that abstract at least some of the coding away from me. I could pontificate a bit more about the wrong-headedness of companies that want to hire a "unicorn" who can design and code, but that's a bit out of the scope of your question :)
As a final disclaimer, I mainly work in roles where someone else will be doing the implementation, so YMMV.
I agree with Dan's comment (i.e., use whatever medium will help you demonstrate effectively to the stakeholders), and would add the following thoughts:
The utility of prototyping does not lie solely in demonstrating a design to clients, but communication is a huge part of why it's useful. When I say "stakeholders" above, I'm including product managers, engineers, other designers, perhaps your marketing team -- anyone who has input into the final product.
It's also a must if you plan to do any usability testing, either in person or with a tool like usertesting.com. What you're after with these sorts of tests (and I'm talking specifically about product design here, which is not quite the same as marketing design) are reactions, not feedback. To get reactions, you need the design to behave as much like the finished product as possible.
I'm going to sound a little dogmatic, but I firmly believe that prototyping will make you a better, more thorough designer. As you prototype a design, you will be constantly previewing it to make sure the prototype is doing what you want it to do. And when you're doing that, part of your brain is thinking more like a user. You'll want to make everything work the way it should. You'll uncover use cases you didn't think about before. You'll discover where error messages should go. You'll find that some of the actions you wanted to have on the page don't make any sense. Etc. My only warning would be not to get carried away! Obsessive Prototyping Disorder can strike even seasoned designers without warning.
Do be mindful about using the right tool for the job. In my experience, static pages of content are fine to do in a static tool like Sketch. Prototyping is an especially useful tool when you have complicated flows and interactions that users will have to go through to accomplish some task. Since you asked specifically about Craft, I assume you're comfortable with Sketch already. I personally haven't used it yet, but if you find it's something you can wade into with relative ease, that would be a good tool you should use. You may find at some point that you need something more powerful for demonstrating more complex interactions. There will be a learning curve, but it'll be worth it.
I'll reiterate the importance of considering the right tool for the job here. HTML and CSS are generally good to have in your toolbox, but I often find that when I code, I spend far too long in the weeds, not enough time actually considering the design holistically. On top of that, a lot of interactions need to be added onto the static HTML/CSS document with JavaScript. What I've started to notice is that the more time I spend coding something, the more I begin to think like a coder. The allure of solving a problem in a technically easy or elegant way sometimes begins to overshadow the need to solve it in a way that works better for the user. There's an interesting phenomenon called linguistic relativity which I suspect is at work here. So my preference is to stick with prototyping tools that abstract at least some of the coding away from me. I could pontificate a bit more about the wrong-headedness of companies that want to hire a "unicorn" who can design and code, but that's a bit out of the scope of your question :)
As a final disclaimer, I mainly work in roles where someone else will be doing the implementation, so YMMV.
Hope this helps!