Why render designs?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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!