Here is an analysis of the pros/advantages and cons/disadvantages of going straight to HTML/CSS from rough paper sketches (or a paper prototype). The alternative is to use a design tool like Sketch, Adobe XD, or Figma
These were my personal notes, originally written in 2013, but updated throughout the years, and should still be relevant today. But if you find something which is not, then comment, and I'll update it!
PROS by going straight from paper to HTML:
- Less illusion of "finished" product which a design tool might give you (and which tempts you into thinking it's a waterfall process). The fact is your first product is just a draft, you need to iterate a lot on. It also contains a lot of assumptions, which might be wrong. A high-res full-fledged design tool mockup gives the impression that this-is-how-its-going-to-be.
- Less focus on "polish" and "details". A design tool will make you care about details such as gradients, icons, alignment.
- Using what you're building will reveal details.
- Work within the real-world constraints of the browser. Constraints can be good for creativity. Limits in thinking can enforce other ways of thinking. Also, the constraints in the browser are the real constraints where the end-product will live. A certain headline might look good in a design tool, but terrible in the browser when the content (of the headline) is of a different length.
- See the end outcome sooner, and spend more time thinking about the end-outcome, than a by-product (.sketch file) which might or might not be equivalent to the end product.
-
You get "Close to Real" (The Christopher Alexander design philosophy). If you believe in that philosophy.
- Progress towards a real product / Less waste. You are significantly closer to a full fledged product. You can expand the HTML/CSS/JS prototype with a back-end directly. If you had done it in a design tool, you'd have to do the HTML/CSS/JS part anyways. Less waste, as there are fewer by-products of the process.
- Favors interaction over visual details.
- More time on the real thing. Less time on byproducts of the process (like .sketch files).
- More DRY. When something changes, you won't have a lot of different artefacts (like .sketch files) you'd also have to update. If you don't update them, you'll be caught in version hell, and wondering which design tool file or html/css version is actually the latest version you decided upon, and if there are important parts in previous versions you've forgotten to carry forward.
- Less custom/tailormade UI elements (which makes implementation magnitudes faster later on). Relieves you of design-tool-to->HTML/CSS conversion problems. Design elements that translates poorly from the design in the design tool to the actual HTML/CSS implementation. Stuff that would be hard to do the way you designed them in the PSD mockup. Hence you might save the implementation time you would have spent trying to fit a square peg into a round hole. Instead, you work with what tools the end environment affords you.
- Most things Just Doesn't Matter. A design tool will lead you into a state of mind where you think details matter, whereas the details don't really matter until later. Especially if you're a startup, and you're just testing to see if the product in general has any core value to the customer. It might be wise to focus on sketching on paper, and strip your HTML/CSS prototype of colors and any visual aesthetics, just to see if the functionality and content is valuable in itself, without the added fluff.
- A design tool typically biases the product towards static pages that show all information at once (and not using dynamic "hiding", or "hover" effects), since it doesn't allow for dynamic displaying of content.
- Kill procrastination. You alleviate the real risk that what you so beautifully sketched out in A design tool typically doesn't materializes into something REAL, that people can actually use. How many mockups haven't you made, that you didn't follow up, didn't show to anyone else, and that ended their life on your computer, before you even began implementing them? The design tool may be your comfort zone. Get out of it, and get "close to real as soon as possible".
- Leveraging your existing knowledge, to move quicker than if you had to spend time to learn something new. You might be a kickass HTML/CSS ninja, and know less of some design tool. If so, then it will probably be faster for you to express your ideas through code. And vice versa of course; if you're a designer who've spent years mastering some design tool, and don't know a lot of HTML/CSS, using the tool you know (and getting a web developer to implement it later on) should get you results quicker.
- Reduces complexity in the process. With one less step in the process from idea to product, you reduce complexity and the possibility that something might go wrong in/to/from that extra step.
Mark Dalgliesh at ReactConfAU 2020 held a talk called 'Rethinking Design Practises' where he made a very good case for going straight from sketches to HTML/CSS. There he also shows how quickly you can iterate on design changes in (JSX) code, using a tool like Playroom (GIF animation speed here might not be representative):
37signals (aka. Basecamp) have a book called ShapeUp, which outlines how to implement a 'straight from paper sketch to HTML/CSS' design workflow. It also notes the important point of Over-specification: "wireframes or high-fidelity mockups [...] define too much detail too early". Which can also lead to estimation errors, since making the interface just so can "require solving hidden complexities and implementation details that weren't visible in the mockup". When having a rougher and more variable scope "the team can reconsider a design decision that is turning out to cost more than it’s worth". And we know that renegotiating design decisions is the most important productivity boost you and your team can make.
CONS by going straight from paper to HTML:
Reasons you might want to use a design tool, since going straight from paper to HTML might:
- Lose freedom / flexibility to change direction easily. As you proceed down the design and product development funnel, you go from Mockups, to PSD, to HTML/CSS, to JS, to back-end. With each step, you get closer to the finished product, but also lose flexibility to change direction easily. Getting "close to real" as soon as possible, might prevent you from exploring alternative visions and designs.
- Sunk cost bias. You are significantly less eager to throw a HTML prototype out the window and start from scratch in another direction, even if that is the right thing to do, because you've invested so much time into the HTML, and you seem so close to a finished product.
- Rushing past and missing a part of the concept phase. Spending more time at the concept phase might allow you to think of more alternatives (i.e. 3 different concepts), be creative, and ultimately steer the product down a better path you've discovered).
- Implementational concerns - you have to think about the HOW, not just the WHAT. You get concerned with stuff you shouldn't be thinking about at this stage. You don't want to think about HOW to do something while you are doing it. You want to think about WHAT to do, not HOW to do it. Using your hand to paint on a canvas is more intuitive than specifying in text how you want your painting to look. Painting on a canvas is intuitive, because you don't think about how to move your hand, or necessarily care much about precision (after all, a few pixels off doesn't necessarily matter much in a rough design draft). HTML/CSS is by definition precision-oriented, so you would have to be concerned with precision (one letter wrong, and it may break the code). It puts you into an entirely different state of mind (See the book: Thinking, Fast and Slow, by Nobel prize winning psychologist Daniel Kahneman). So unless typing text in HTML/CSS or a component language feels like such a natural extension of your mind that you don't have to think about it while doing it, then it will occupy mental resources which could otherwise be concerned with higher level design considerations. You should be able to think about the look and feel of a design without having to think about HOW to achieve that look and feel (even if that HOW is simply: how to write the declarative code which specifies what should be rendered). Additional concerns that could pop up could even, but not necessarily, extend to CSS frameworks, Asset pipelines, template issues, etc.
- CSS bugs breaks your psychological flow-state! You shouldn't be thinking about how to write the CSS that will horizontally align that box at the right place on the page; for example by using either floats, inline-blocks, CSS Grid, Flexbox, etc. It will make you go slower. Especially when bugs inevitably crop up. See also the point about implementational concerns, for more on the psychological aspect closely related to flow.
- Skips the emotional design. A design tool allows for more emotional expressiveness, and also get's you into the right frame of mind. CSS will get you into an analytical/logical frame of mind. It's easier to be emotive in a design tool than in CSS. HTML/CSS caters to the logical side of the mind, while a design tool caters to the visual, aesthetical and emotional side of the mind. This is also why designers and coders are often very different kinds of people. Your product should not overlook these different sides of the mind. It would be wise to remember that: The end product is shaped by the tool you use to make it. This can often be viewed in straight-to-HTML products like Quora, that started by skipping visual design. Contrast this with Apple's webpage, which is all about visual design.
- Redoing large areas of HTML/CSS/JS is costly! Since reworking something in code can take a lot longer than simply moving some diagrams around in a visual editor. Incremental changes are fast, however, but going in completely different directions with the design takes more work in code.
- Limits creativity. The boundaries that HTML/CSS enforces may limit your free blank-sheet thinking.It might tempt you to make a more standard design (i.e. forms), since the standards make it easier to go in a certain direction. Your tools are limited by the current state of the component system at the time, and the browser you're designing in. This might be a good constraint to have in some situations, because you might hit those constraints later when implementing your design anyway. But it certainly limits your creativity, for better and worse.
- Temptation to flesh out back-end. If you go straight to HTML/CSS/JS, you can easily get tempted to code just a little bit more. Especially if you're thinking about making a one-page-app, where a lot of the final code will be in JS anyway.
- A design tool is better at communicating a vision of what the end product should/could look like. It can take some time before you get your HTML/CSS so good that it can communicate the glory of your product in it's fullest detail (Just finding the right jqeury library/plugin/snippet for a specific dropdown menu might take ages in itself). Going straight from paper to HTML/CSS will be more messy at first, and influenced by pragmatic choices. For selling in the vision to a customer/investor, I'd recommend using a design tool instead of HTML/CSS, as you faster get to a beautiful and awesome visual impression. And visuals sell, as we all know. (The visual reward makes visuals more sellable than interactions, unless the interactions are really fun/rewarding).
- You might miss the part where you focus on aesthetics, visuals, colors, fonts and gradients. If you sketch in black-white on paper, and go straight to HTML/CSS, then your HTML/CSS prototype will probably be more functional than beautiful. It will look similar to the paper prototype (the design you're trying to implement) which has few/no colors and gradients. And you might think you'll "prettify" it later; but should there even be such a thing as 'prettifying' in product design, or is that an erroneous way of thinking? And do you really ever get around to tasks that you say to yourself you'll finish later? Some styles don't work very well when it comes to designing them in the browser. A design tool is useful for creating so called mood boards early in the design process.
-
A design tool is better than HTML/CSS to quickly iterate on stuff like:
- moving layout items around - (otherwise it would potentially require a structure change in the HTML and a change in the stylesheet). Doing it on paper would be more cumbersome, and you'd run out of paper if you were to try a ton of different positions really quickly. In a design tool, it is effortless.
- visual prioritisation - using colors and gradients; something that might look like information overload in only black-and-white, might be easily consumable in shades of gray, and with some color that makes important items stand out.
- visual style - driven by i.e. textures, and glossyness and shape.
- A design tool is typically quicker to learn for a newcomer, and you'd more rapidly be able to express your ideas to someone else, than through HTML/CSS.
- Images (copy-pasted into your mockup) can enhance your prototype and give you a much better impression of the final product, than a paper prototype can. It would also take longer to include them in HTML/CSS, and get them into the flow of content on your page in a good way, than simply copy-pasting into a design tool.
- A design tool makes it easier to compare and contrast different designs, side by side. In HTML/CSS you would have to open more browser tabs, and make sure you don't refresh the page that had the old CSS loaded.
- Less refining of product before production. You could look at the process of taking your paper sketches through a design tool before going to HTML/CSS as a step of refining ("purification of a substance or a form") the product, before it goes into production. This might be what you want though, if your intentions is to quickly test a design in practise. Be aware though, that what you do tends to stick around, and tasks you skip tend to be forgotten / considered as less important, once you don't have a specific problem or trigger that will bring it up again. (See again the Quora screenshots as an example.) So it might have some worth to do something well once you decide to do it, since being able to put something behind you (with no open loops) is a good thing.
My conclusion:
There is no "always do this" or "always do that" kind of process that will ensure success. Even though we'd all like it to be, so it would relieve us of thinking about the process underway.
Process isn't a guiding star that will always ensure good outcome.
Your available resources and goal should determine your process, and what you see as useful.
Not everyone has people who has both visual design and front-end coding skills. I presume there will always be people who are more comfortable/skilled at laying design out in a visual editor than by using code. Specialisation will likely also maintain the distinct roles of visual designer and front-end coder. So the process you should choose should depend on the skillset of the people you have. Unless you are doing the work yourself and possess an adequate amount of both skillsets. Then you can choose either approach, and the aforementioned choice becomes a more acute problem. I would suggest you try each process out over a short period of time to see what you like and what you gain/lose, and then share your experience by commenting on this post.
The overall focus should be on "What do you need to learn from the customer?".
If you should go via a design tool or not depends on your end goal. Can you get feedback and learn something faster by using a paper mockup, a design tool, or a HTML prototype? Paper often wins, but for some things like visual appeal or interactions then design tools or HTML prototypes work better (just make sure the customer doesn't think your HTML prototype is the finished product...).
I'd use a design tool for certain elements, and for sketching out one or two images of the product in high-res, to get the feel of the product, and use it in "selling in" the vision to the customer.
I would disadvise using a design tool to make a full fledged prototype/mockup of the entire product. That is way too time consuming, and when something changes it will be hard to update. Mockup only what you need. Oftentimes, creating 4-6 essential screens in a design tool is enough. (The standard login screen, or a settings screen, are not one of them.) Things will likely change a lot anyway. You just want a clear picture of the vision.
Some final questions:
- What does a design tool allow you to do that paper does not? And should you even focus on those things, if you could?
- Is your design tool mockup a one-time-use, before going into HTML/CSS, or do you expect to iterate on it with customers before, or after, going into coding?
- If you only had until the end of the day to reach your goal, how would you do it? Do that. What parts can the product not live without? Start there. Then do the next most important thing afterwards, in a second iteration.
PS: These arguments should be relevant whether you use Sketch, Adobe XD, Omnigraffle, InDesign/Photoshop, Figma, or any other visual design tool, graphical editor og visual mockup tool.
1. If something is unclear, message me, and I will iterate on this post, until it's clear. :-)
2. If you disagree with something, please say so, and I will take it into account and reconsider my arguments. These are just my first thoughts on the subject matter, so I very well might be wrong in one or more of the arguments.
What is your experience?
Top comments (0)