DESCRIPTION
- Rethink in-browser design
- What is the deliverable for web design?
Main Text
How "Web Design" Deliverables Differ on Crowdsourcing Sites
What is the deliverable for web design? Of course the textbook answer is "it depends on the site and the contract," but on crowdsourcing platforms I noticed an interesting difference: deliverables for requests in the "Homepage production / Web design" category on the two largest players, CrowdWorks and Lancers.
On CrowdWorks you can select multiple deliverables. They are as follows.
Illustrator or Photoshop format is realistically either/or (importing as-is does not help much anyway...), and the rest can be exported from those, so they are effectively the same file.
But Lancers! Delivery format (method) is as follows!
The idea is "web design deliverables are basically a set of HTML/CSS files, so file handoff means a ZIP" and "there is also handoff to a server." You can see how CrowdWorks and Lancers think differently about web design output.
| CrowdWorks | Lancers |
|---|---|
| Image format | HTML files |
By the way, on Lancers too, if the request is for a banner or similar, the questions switch to image save formats like CrowdWorks. Neither is strictly right, but I personally strongly prefer Lancers.
In-Browser Design
What do you think of when you hear web design tools?
A little while ago, maybe Adobe Illustrator. Now many "UI design tools" have appeared, and newcomers like Adobe XD and Sketch compete for dominance. Easy preview, mock, and sharing features make design work vastly easier than with PhotoShop or Illustrator, or so they say.
But I want to say this loudly.
You can do that in the browser.
If you show a whole site as one image, ignoring responsive layout, accessibility, and search bots, design tool display and browser display match—but when you implement in code, design tool rendering and browser rendering differ. The browser may do what a UI design tool cannot express; the reverse never happens. No matter how great the design in a UI tool, it means nothing if you cannot implement it in code.
There has long been a method called "in-browser design."
- Productive CSS in-browser design! Let us stop design roughs in Photoshop
- Why is the shift to in-browser design necessary?
What UI design tools aim for is, in a sense, only a substitute for this. Screen transitions? Of course they exist if you implement in the browser. Sharing? Set up automatic deploy and share a URL so people can check progress itself.
I will set aside for now that Adobe XD has a feature to build animations wholesale and export a game.
Where a Web Designer's Canvas Is
Design tools may let you design with GUI alone. But essentially that is the same as a rough sketch on paper. It is not web design but instructions for designing on the web—a memo, nothing more. That is what Lancers is saying. (Covering myself.)
But when you think about it, it is fairly obvious: a designer who makes plaster statues does not deliver a detailed plaster statue sketch saying "this is the plaster statue design"—they deliver the plaster statue. If a designer delivered only a Buddha sketch saying "make a Buddha like this," they would be delivering an idea, not a design.
I wrote at the start that neither side is strictly right, but in current web design (especially in schools for it), there is a strong tilt toward design tools, and even if not all the way to in-browser design, I think it is important to look harder for a middle ground—a compromise.
See you again.