How do you use mockups, specifically high quality mockups (not wireframes), in your design process and why/would you recommend them?

I'm a developer, in the past my product owners would sometimes give requirements in the form of mockups, but even then it generally struck me that it could've been communicated without all the extra work (0 artistic ability w/ a pen and paper sketch would've sufficed).

Last week I was watching some YouTube videos to get some design inspiration for a side/hobby project I'm working on and found myself emulating some of what they were doing, but stopped when I realized that the effort didn't carry over. Most of the design software I've seen looks more like Photoshop than a web browser so the normal canvas/palette work doesn't translate readily into (S)CSS -- I've never (*not since the early 2000s) worked on a project that used a background image so I'm not sure what role the sketch plays in a design/develop life cycle?

I'm not knocking designers or the work you do -- I remember the internet in the late 90s and don't want to go back, I'm just struggling to understand why companies spend so much time/money generating high quality digital art -- that then needs to be translated into images, HTML & CSS?

  • Have you ever tried to edit a "pen and paper" design? It's doesn't work so well, and it's very unlikely you will get it right first time.
    – musefan
    Oct 8, 2020 at 8:08
  • What I'm thinking about is SUPER rough; rectangles on a page, but point made about editability; still photoshop seems like overkill
    – Schalton
    Oct 8, 2020 at 14:17

3 Answers 3


I think the ideal scenario is having designers who code front-end. But the reality is most designers don’t. There are, however, more and more places where that’s the norm.

From the designer’s point of view, the designs serve primarily 3 main goals:

  1. Critique within team
  2. Test with users
  3. Discuss with clients

Paper sketches can’t be used for any of the above, even wireframes are hard to understand for clients and some users. Since every item has its purpose, sketching on paper (like sketching on a whiteboard) is best to facilitate a quick discussion about something minor or an idea, it can’t possible represent things like branding, look and feel.

Another place where it shines is portraying initial rough ideas to tweak quickly. There are things called paper prototyping, or cardboard models of products etc. They are often used to run through a scenario and get the sense of how it feels to use the product and if the vision has any big holes in it. It’s easy to miss important things when not acting it out.

Now, both hifi prototypes and straight html/css satisfy the points above. It just depends on the designer and the company internal processes. There is no rule stating hifi prototypes are a must.

What you use depends on what you need and project constrains. Need to communicate something that can be done by sketching on paper? Please do so, don’t waste time. Do it anytime at any point in the project. Need to test with users? clients only understand hifi stuff? Have designers living in html/css? Feel free to skip the photoshop/figma/sketch, etc. Have a client requesting exploring 2 very different avenues? costs less to iterate on prototyping tools? Then skip the html/css for a bit.

In many ways, the wireframe > photoshop > code flow is legacy. Tools now are blending wireframes and photoshop with logical rules. Some of these prototyping tools start to complicate it so much (they basically become visual representations of code) that makes you wonder if it’s faster just doing directly on javascript (which it is if you are technical). I am sure this evolution will continue to move more and more code-only. The field is evolving, there are many new people entering who are not technical. And the tools you see are catered to them, not to front-devs.

There is also this concept of fidelity. The more something looks like the final product, the more people believe they can’t give feedback and changes. They will hold back even if you tell them it’s ok to give. So a wireframe will naturally invite more than something that looks polished and finished. Showing a client a polished designed may not give you the feedback you seek for. But again, you could code a wireframe instead. Nobody is saying you can’t.

  • @Nicholas; thank you for the perspective/context; coming at this as a developer I think I was a but unempathetic to the technical toolkit of designers and clients. Following up; it seems like a lot of the things I've seen drawn on hifi prototypes can't actually be used in a responsive design -- specifically talking about sketched backgrounds -- is there a translation step you could point me to? I'd love to understand what devs, in the wild, are doing with these hifi sketches -- if a designer gave me one I'd probably end up stretching it all to hell to get it to fit different aspect ratios
    – Schalton
    Oct 8, 2020 at 15:48
  • Yeah that’s another benefit of working in code, makes you understand the constrains and limitations (resource-wise and technical-wise) to pull off crazy stuff. I can’t really understand the second part of your question. Could you start a new thread and include images?
    – Nicolas
    Oct 8, 2020 at 15:57
  • @Nicholas, I'm going to try this the lazy way (I think it's a small question; if not, I'll post another thread) I see a lot of design sketches where the designer creates a mobile & desktop view of each page, but the background images are two different assets that are tailored for the screen -- it strikes me that I can do a media switch/src switch to render one but at that point I'm not really using the scalability of the vector image.
    – Schalton
    Oct 10, 2020 at 16:46
  • If you look at an apple product page on a desktop, for instance (apple.com/ipad-pro) they're not rendering an image/gif and using css to translate/slide it, spin around the page - each frame is a new image. I may have answered my question -- their mobile & desktop sites are basically two distinct sites and they're using different assets for each and have a set of assets that scale from phone->ipad and another set of assets for their desktop site --- nvm
    – Schalton
    Oct 10, 2020 at 16:53
  • @Schalton yeah so keep in mind that the mockups from the designer already carry a lot of decisions made by the team and the client and can have branding, marketing, content, etc implications. In a perfect world, the developer should be involved earlier to start having an idea of the future work or advice on better options. What I'm trying to say is to keep open communication both ways, if something is technically inappropriate or a better solution exists, discuss it with the team.
    – Nicolas
    Oct 10, 2020 at 17:02

Because Designers don't exclusively do that to communicate with developers but rather to communicate with users and steakholders.

How do you test a design solution you scribbled with pen and paper? How do you find out what solution generates a better conversion? How do you know if you need to adapt your solution because users find it hard to understand etc.?

Designers do this so they can work out something together with steakholders, which are usually people that are visual type persons and also to validate their work by testing it with users.

At the end the design solution gets carried over to developers and tools like sketch, adobe xd etc. provide a way with rather small effort to communicate styling attributes etc. to developers from the work you already did.

  • High fidelity graphics also make better prototypes for testing with things like Invision or Axure. This, in turn, means that your test users react more like they would do when the product is complete. Oct 8, 2020 at 7:17
  • It seems like you guys are talking about wireframes -- are sketches/renderings the same as wireframes in the design world? It seems to me that most UI setups are pretty standard -- for instance, there's a tremendous amount of literature around how a form should be laid out. I guess is strikes me that with a few sketched rectangles w/ labels and input types I could throw the form elements on a page after that a designer could modify the css to create the aesthetic they want
    – Schalton
    Oct 8, 2020 at 14:23
  • I'm by no means discounting the work designers do; it's really clear when a site was built without design support. I'm really focused on how to make that work efficient (from a development standpoint) To the question about wireframe vs drawing; maybe you guys are using tools I'm not familiar with. I saw a video where a guy built a beautiful login page using affinity designer but was left thinking -- how the hell is he going to translate that to a responsive website without a million different background images
    – Schalton
    Oct 8, 2020 at 14:28
  • I just watched this video (youtube.com/watch?v=BZXctkpzisc) but I'm left thinking, this is cool but it doesn't translate to the website -- the 'landscape' he created doesn't seem responsive; and there's so much information lost in the border radii and the blurring His, albeit simple, UI really just translates to a button, text and footer. I could create that in 5 minutes then he could do all his design in css. It'd be mutable, links would work (for demo/user feedback), he could tag and modify items as classes It seems like it would improve the design exp and reduce rework
    – Schalton
    Oct 8, 2020 at 14:50

We gave up on actual rendered designs at my work a few years ago. we moved to rapid prototypes using proxy/mock json as the backend. our stakeholders get the feel of a real app and can critique it early on with no backend code developed. We all are decent UI designers too though and we use bootstrap as a base. After our prototype is done/approved we start the backend because the front end is literally already done. We use a custom javascript framework called atomic stack written by Tyree Jackson. Check it out!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.