It does help a lot with:
- Understanding what is wanted from you
- Understanding the bounding boxes, element positioning, layouts, viewports
- Understanding how the client/organization wants the elements to interact with each other
- Therefore understanding the nature of the glue code
- Therefore understanding which strategy/library/framework would be suitable to model the glue code + view + state etc.
After you are done, it will also save you:
- From the pointless discussions because you did your work with respect to the 'mock-up'.
Adding to what Ibrahim mentioned, If there is a strict deadline and the focus is on working functionality rather than design and UX elements then frontend dev's creativity and imaginative should be enough otherwise mockups will help for extending the design in future for new addition of functionalities.
In a nutshell: for protoyping or mvp, mockups are not necessary otherwise mockups can be of help.
With the clients I deal with and the needs of the final result, NOT ONE JOE-DAMNED BIT!!!
This is because I work with sites that need to meet WCAG accessibility minimums, something ALL sites should strive for and most of the scripting junkies and artists under the DELUSION that they are "web designers" are so woefully ignorant of, they have little to no business "designing" a blasted thing on the front-end!
See, CONTENT dictates markup, because the point of markup is NOT to say what things are going to look like, it is to say what they ARE! <p> is a grammatical paragraph not just "some text" or a image all by its lonesome. <ul> and <ol> are short list of bullet points or selections. <table> is tabular data. <b> is a proper name/legal entity. <i> is a book title or other reference. <em> is for emphasis. <strong> is for "more emphasis". <h1> is the heading across all pages that everything on every page is a subsection of. <h2> marks the start of a major subsection of the page. <h3> marks the start of a subsection of the <h2> preceding it. <h4> marks the start of a subsection of the <h3> preceding it and so forth. Even <hr> doesn't mean "draw a line across the screen" it MEANS a change in topic or section where heading text is wanted or unwarranted. Only a handful of tags apply no meaning to their content; specifically <div>, <span>, and <a> which is why the former two have ZERO business being added to the markup during your semantics stage.
Which is why if you know the first thing about the INTENT of HTML 4 Strict or even HTML itself, the WhatWG was clearly unqualified to make its successor, hence the idiotically pointless section, article, nav, main, header, footer, and aside tags that are all either redundant to numbered headings and HR or are outright presentational HTML 3.2 style. (yes ASIDE, I'm looking at you!)
... and that semantics and content (or a reasonable facsimile of future content) should be completed BEFORE YOU EVEN THINK ABOUT LAYOUT!!!
CONTENT FIRST, then the markup, THEN the layout, THEN hang your presentation on it, and once you have a fully working page THEN you put scripting on top to ENHANCE the functionality and usability if desired! It is called progressive enhancement, and is the fast-track to creating layouts that meet accessibility minimums, are useful to MORE than just the perfect mix of perfect vision on perfectly sized screen media targets.
To that end spanking the crank on a graphics tablet in Photoshop IS NOT DESIGN! It's art. DESIGN is engineering that incorporates not just art, but specifications, accessibility, usability, limitations of the medium.. and that's why 90%+ of the garbage that starts life as a "mockup" -- at least in terms of using some glorified paint program -- are most always slow loaded bloated train wrecks of ineptitude and ignorance if you care in the SLIGHTEST about visitors to the site.
But that's something your marketing turds who should stick to their halfwit print infographics and PSD jockeys under the DELUSION that they are designers often miss out about websites. They are for MORE than just sighted users -- as I often joke search engines don't have eyeballs either. Websites exist to deliver CONTENT to USERS -- anything that gets in the way of that? Get rid of it.
End of the day, people visit websites for the content, not the goofy graphics and goofier layout trickery you hang around it!
When I say "architectural design", "automotive design", "electrical design", or "mechanical design" do you picture some hipster in skinny jeans drinking a Star*ucks latte in some goofy nonsensically named size wearing horn rim glasses they don't actually need trying to decide if they should trade in their Prius for a Leaf, or do you picture some dork in khaki's double-pounding a pair of Dunkin's extra-large dark roast cold brew double-cream double-sweet wearing aviators wireframe prescription glasses browsing auto-trader looking for a replacement bumper for their 1984 Saab 2000 Turbo?
So why do we treat web design differently letting the artsy-fartsy types who know Jack about **** dominate an industry THEY DON'T ACTUALLY KNOW THE FIRST BLASTED THING ABOUT!?!
Let's just say friends don't let friends drink Starbucks.
You want a "mockup", do it with HTML and CSS starting with the CONTENT! ANYTHING LESS IS NOT DESIGN!!!
Depends if the designers have to sign off before it goes live...! ;)
You can start building the structure of the project as soon as you know what content goes into it, but if the design is a key part of the project you really need to be working with the designers from the start. Otherwise rework and delays are inevitable. Also if you want to influence the design (say to get accessible colours, or to avoid a structure that will be costly in the data layer) it's a hell of a lot easier to do in the earlier stages than close to deadline.
Depends on the scope of the project.
If the project demands something simple that's been done, and the components basically exist, there's not much mocking to do. All the preferential choices (color, this thing left or right) all can easily happen during the prototyping phase, or even further down the pipeline. One column blog? Got you. Simple contact form interface? Would you like Bootstrap, Polymer, or Material Design?
If the project is complex with a significant amount of components, or we're trying to do something new and think outside the box -- you always mock. It helps work out ideas on the ground level before you waste time and take a risk executing an unrefined vision. It takes planning to create an artistic yet intentional landing page for an app or service that doesn't look like every other 968px grid CTA->3-col->CTA template.