Write your answer…
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'.
This is what i feel : Mockups is kind of check points and helps a team to define a complete visual components that clash, before you arrive for the development. The complete developed hierarchies shows the difference between design elements for example color, font etc. With the visual components justifies about the look and feel of the end user side of product which should calculated in initial stage only.
Checkpoints we can discuss here:
- Helps to debug more in details how the mapping will work for site or app.
- Generate a clear picture for developer
- Translate your idea for end- user and stakeholders
- Helps to build a good plan which saves time as well as money
- Find errors early on
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.
The Dev Community
Free, friendly and inclusive platform for developers
Or connect with