Problem with designing in code is that it starts to influence the design too much if there's friction in implementing a certain look.
The advantage with Photoshop is most things take a similar amount of time , so you're not subconsciously changing the design based on what's easy / hard , but just what end result is best.
Ultimately if there are multiple break points then I think each should be 'designed' , not just left up to the whim of how its turns out in css.
> Problem with designing in code is that it starts to influence the design too much if there's friction in implementing a certain look.
Depending on the goals of the project, that isn't necessarily a problem per se. One of the things we've been working on at my current employer is finding that nice balance between "amazing, interesting designs" and "not impossible to implement". What's fun is that if you get the balance right, design and development flow into one another so perfectly. Avocode with Sketch helps a lot with that, mind you.
I'm kind of allergic to doing things just because the sake of it, even with design. Start with what you have, which is pure text. Then you look at the text and you ask your self, how do I make this more readable? Design is about function and not about looks. If you begin the design process in photoshop your starting of in the wrong end, because then you start with looks before function. I can however understand why people tend to do this, because it's therapeutic and relaxing to just throw painting on a canvas, and you feel good about it, but will it lead to good design? Most often not.
I am not a designer, but I disagree that design is "not about looks". My gut feeling is that the goal is not just to make things easier to use, but also to make people want to use them, and for that looks do matter.
I think this is a result of people starting with the decoration rather than the tool they chose. I'm primarily a programmer, but i'll always fire up Sketch (previously Photoshop) if I want to do any design work.
Much like the author of the article, I find that designing in the browser doesn't use the right parts of my brain. I don't just mean in the sense of decoration.
Apple - they sell hardware with worse specs at higher prices than their competitors, the design is what makes it worth it.
Skype - people talk about their video/voice support but my friends don't even use that, just the chat UI is better. (Or was - these days Slack is displacing it for the same reason)
Uber, if you count them as having won yet. There are plenty of competitors with the same functionality (at least here in London), I think the incredibly beautiful website is a big part of what's keeping them on top.
The type of paintbrush you use does not need to limit the painting you can create, but it may mean you have to approach it's usage differently.
Wireframes are good; just give me a thick marker and some pencil (or a dry erase board) and i'm set. Sometimes you need to bring photoshop in, but rarely for concept work, more to produce parts.
Also, where / when you stop designing is up to you. If you're not satisfied with the way things look, how you got there is not to blame, not enough iterations is. Start with a solid foundation and add nuances from there, instead of trying to build a full scale house out of paper.
I held up the belief that you should design right in the browser and skip the design phase. But I came to the same conclusion as the author: thinking in code is a completely different process than drawing things and trying out how your site might look like. My best advice is: draw on paper first, using just a pencil and an eraser. This forces you to focus on structure and relationship rather than pixel-perfection. Hence, by going analog, you focus on function rather than on design as the critics say.
What you do next is up to your preferences. I think it is worth it to transform your sketches to wireframes. In most of my cases that was still a more open process than fitting the sketches into CSS directly - especially if you have designers, business people and coders involved.
One possible solution for wireframing that was already available in 2012 is Illustrator or InDesign. Both have global colors, symbols for reusable content and are vector-based so you can scale it for your responsive designs.
There are less good ressources on wireframing with Illustrator, but I found these two most helpful:
I admittedly don't think as much in terms of finer points of design so much as usability, and often how structure plays with that... I think about how will this be used. I'll usually only go so far as to create mockups in something like balsamiq, and code as a followup. I find that delving too far into specific aspects of look/feel tend to block the purpose of what's being built.
The exception to that being something that is mostly serving as a static content/advertisement/landing page etc... A lot of the time people will try to go too far outside the box.
That said, I also spend a lot of time dealing with software that anyone should be able to use... this has lead me to the firm belief that if you try to make something idiot proof, they will only build a better idiot. It doesn't mean that one shouldn't try.. but it does mean that sometimes you shouldn't stray too far from convention...
Also, most programmers make lousy interfaces left to their own devices...
In my opinion pen and paper are fundamental. Not just in design, but also in programming. There's a lot to be gained by just thinking over and sketching ideas for something rather than just diving into action.
I could not agree more about the role of paper for coding. I used to jump right into action and got lost very quickly in details and gave up soon after. Now I try to slow myself down and do sketches about quite everything. Database design seems to be of a special importance, as it hurts so much the find out later that you did not think hard enough and forgot too many cases that you need to incorporate in your database schema. Slowing down with all screens off and mind on certainly makes a huge difference in my workflow.
I hope this isn't considered spamming, but for anyone wanting to sketch a site or app on paper, I created some simple, free templates for web sites or apps. The templates are CC licenced and you can create your own sketch sheets too.
I think this is a similar (though more annoying) issue to what we go through in engineering at times. Before coding, my workplace likes to draft up design documents that specify the what, the why, and (sometimes) the how of what we're about to do before we go and do it.
In a way it's like using Photoshop in that the nuances of the language don't really impact the plans at the time, though losing the prototyping can be annoying. But this metaphor does break down because I think the problem she illustrates is far worse.
This post was written before the time of Sketch (Bohemian Coding). A few designers I respect swear by the tool, and as a developer I'm all for it since it respects the way web works. It is a vector-based application, and everything you do in it can be represented in CSS (they even have a 'Copy CSS' function), and if not, complex shapes are available as SVGs.
If you're a designer using Sketch, I would love to hear your experience with it, and also any thoughts you have on how it has influenced your workflow.
I don’t use the CSS export however, and I still use Illustrator or Photoshop for SVGs due to superior export options.
I actually learned a few tricks from my colleague who has a great Photoshop workflow, and Photoshop really can be whipped into shape…
but Sketch is already so close to the mark straight out of the box… but without the bloat Photoshop has acquired over the years as the industry standard for everything.
Plus, it’s the simple things — the color picker, how it handles border radius, the fact you don’t need to worry about layer management, etc.
I understand that the typical Photoshop workflow became burdensome, but to fly wildly off the other end of the spectrum and design directly in the browser never made any sense to me.
A critical step in any design process is experimentation, which typically involves bouncing between sketches, high fidelity mockups, content strategy, structure and user flows, and evaluating technical opportunities/constraints.
That said, I think the underlying ideal is about embracing the web for the medium that it is — and not a digital incarnation of print/graphic design. Which is fair.
This is from 2012. I'm not sure how relevant it is anymore. As tons of others have mentioned here, tools like Sketch help to bring designs closer to implementation. Also, "design in the browser" was never meant to mean "forgo all other parts of the design process and just start coding." Some people seemed to skip over that.
I love that we're in an era where we expect sites and interfaces to be more than just desktop pixel grids. Designing in the browser feels like you're actually crafting something real, the same way a carpenter is refining the actual pieces of wood until it turns into furniture.
If I don’t have my design to follow, the whole process breaks down for me. I’ve tried, goodness knows I’ve tried, but my designs end up suffering, looking boxy, bland and uninspiring.
I can see there being some users here (including me) who would think that's actually a good thing... unless your goal is to make an extremely artistic site.
If you don't know code then use Photoshop, get it approved by the client and get a project manager to get a developer to come up with whatever it is you have designed. Easy.
The advantage with Photoshop is most things take a similar amount of time , so you're not subconsciously changing the design based on what's easy / hard , but just what end result is best.
Ultimately if there are multiple break points then I think each should be 'designed' , not just left up to the whim of how its turns out in css.