If we're talking about landing pages that don't necessarily need to be strong on the code side since you don't expect people to just google them up, there are a lot of generators out there.

All of these tools generate super bad and unreadable code, possibly even making the page non-SEO friendly. However, if your employer is doing some other things to get people on that page and do some stuff (download the product, ebook...), then it's just fine.

Most of these tools exist so that the marketing departments don't have to sit and wait for the development teams to make minor changes when they can just reposition the elements around the page themselves.

If you're wondering how to make a clean & performant page from ground up, with the goal of helping your colleagues, then maybe ask them if they'd want that. Fixing someone else's code takes more time than just writing it on your own.

SIGH

Ok, the first thing you need to learn about HTML and CSS is that EVERYTHING you think you know about graphics is now irrelevant, and what you THINK is a design isn't. What you have is a pretty picture -- most likely it is filled with accessibility failings, layout failings, and a lack of core semantics REQUIRED to build a website that's worth a flying purple fish.

Photoshop, fireworks, etc, etc, ARE NOT DESIGN TOOLS!!! They're over-glorified paint programs that have next to NOTHING to do with web development; no matter how many PSD jockeys under the DELUSION that they are "web designers" might claim otherwise. Starting out with a picture of what could be a website is utterly and completely back-assward, the opposite of accessible design and progressive enhancement, and universally results in websites that tell visitors to go perform anatomically impossible acts upon themselves.

Apologies if that sounds harsh, but that's the TRUTH of it.

See, DESIGN is engineering that incorporates art, and NOT art unto itself for art's sake. This means you need a base knowledge of limitations of the medium, specifications, guidelines, accessibility, usability, and a host of other things that dicking around drawing pretty pictures isn't going to give you.

HTML was created to say what things ARE, grammatically so that the user-agent (software that conveys the content to users, a browser is a UA but a UA isn't always a browser) can best convey that meaning within the limitations of the device or the user. This means your base HTML is for MORE than just the perfectly sighted user sitting at a visual browser. It's for the blind, it's for the impaired, it's for search engines (which also don't have eyeballs!) Only once you have that base "semantic markup" (a sick euphemism for using HTML properly) do you have any business even thinking about starting on the layout for visual users.

That's why the PROPER design process -- if you care at ALL about usability and accessibility -- should follow these steps:

queue broken record:

1) Take your content or a reasonable facsimile of future content, and arrange it in a flat text editor as if HTML doesn't even exist, in an order that would make sense if it were just a normal document.

2) Mark it up semantically saying what things are -- paragraphs for actual grammatical paragraphs, images for content images not presentational images, numbered headings and horizontal rules to create logical document structure of sections and subsections, lists for short bullet points or selections (as in a grammatical bullet point, not "hurr durz its has uh dotz befurs ut"), etc, etc... IT even means tags like "B" for legal entity names, "I" for book and reference titles, "cite" for citing sources, "em" when emphasizing text, "strong" for "more emphasis"

If you are choosing ANY of those tags for their default appearance or how you want the page to look, you're choosing all the wrong tags for all the wrong reasons! Sadly I just described around 80%+ of the HTML in circulation right now.

Since that's the semantics stage neutral tags like DIV and SPAN don't even belong in there yet.

2) Create your desktop media layout applying DIV, SPAN, ID's and classes as appropriate but only when needed. I say start with the desktop layout first since we cannot target legacy desktops with media queries to make them responsive. Some people say to start with "mobile first" and that's utterly back-assward since that's what we CAN target with media queries. This is why "mobile first" is usually best translated into English as "f** legacy desktop users"*

3) Use media queries to add/remove columns and adjust other layout elements so as to best fit the available screen space.

4) Then and only then further enhance the already working page with JavaScript where and as desired. Keeping in mind that if core functionality doesn't work scripting off, you could land in hot water on accessibility grounds!

THAT is design. Playing around in a paint program is not, and is why picture based mock-ups are often little more than a scam used to dupe people who don't know any better into signing off on broken/bloated/useless sites.

You want to make a mock-up, do it in the code!

If nothing else when the client says "Can you make the space around that bigger" or "can you make that column smaller" it's a lot easier to change the padding or width declarations than it is to sit there screwing with layers in Photoshop!

We used to have such softwares that transform WYSIWYG graphic into bunch of code. But noone work like that anymore.

The more you can do to work with coders is to give them data about your design choices: margins sizes, fonts policies, colors used, etc.

The designers in my work team use zeplin.io, see information it gives when you browse the design sheet.