What is the 2016 Web Design Workflow

Question

I am a front end web developer. I have a small team and our designer is really new and I wanted to help her out with what I can. She has a hard time staying inside grids, using equal margins on elements, etc.

Back when I started a few years ago, I got all my designs from the designers in a PSD Photoshop file and I started to code them form the grounds up. I still prefer coding my self, as we build complex Apps/Websites, using Laravel and so on, that will not benefit from a generated markup (god forbid export to HTML from Photoshop).

What is the current situation with Modern Day Web Design? I read that some are designing directly in the browser. I as a front end geek wouldn't let a designer even near my code.

Photoshop is just too much of a hustle with grids, keeping spacing between elements uniform, reusing elements (linked smart objects sort of help).

I know about InVision and Marvel, but they are for Prototyping, I recently introduced them to our workflow and its really useful.

What is used to generate the design, so the client sees it and says "YES, now start coding".

We are using Windows so Sketch is out of the equation.

Answer 1

The 2016 workflow is the same as the 2006 and 1996 workflows: a random chaotic mish-mash of techniques and processes heavily dictated by arbitrary decisions made by different teams working on different projects.

I think most here would agree that the pixel-perfect-PSD file tossed over the fence to the FED (front end developers) to slice-n-dice flow is quite antiquated. Yet, it's still used way more than most of us would like.

TL/DR: Each team needs to find and/or fight for a process that works for their team, their client, their needs. Hopefully it's less Photoshop, more in-the-browser as time goes by.

Answer 2

Try using Adobe Muse - Its been designed for print designers who have no idea how to write a single line code but yet their able to publish websites live on the web. I don't recommend using this tool for going live as the markup could be coded a lot better doing it yourself.

Personally I believe its great for wireframing, responsive design and most of all you can show the client directly in the browser, on any device, skipping the whole PDF presentation where you try to explain interactive mock ups like drop down menus etc.

Also you can publish the design via muse so the client is up and running with a new website as soon as they sign off the design. This allows you to do some A/B testing in the real world before you build the final version or simply it just gives you a little more time to build it without the client hassling you to rush the build stage.

Unless you are very good at coding the web, designing in the browser may take a lot longer and hold back the freedom of creative design. But if your able to pull it off day after day then fair play, keep doing it?

For your new designer, try using websites you've already created or you found online and lay a grid over them in Photoshop or whatever you choose to use and then write comments on top and around explaining visually how designers use the grid. Also, draw boxes around elements and sections and toggle them and the grid on and off to help understand layout as well.

Answer 3

Like Cai commented..... I design directly in browser. But I design/code myself so there's no other team in play unless it's a back-end team, never a front-end team.

What I, personally, do for approval.... I actually still design directly in browser.. then take screenshots for approval. Admittedly this means a designer needs to have a great understanding of HTML/CSS (maybe JavaScript paired with jQuery too). So, it's not necessarily feasible for all situations.

_{Random rant... I've never understood how someone can call them selves a "web site designer" without understanding HTML/CSS. Making pretty pictures in Photoshop doesn't mean you can design a web site. It just means you may be adept with Photoshop.}

If needed, I will actually throw together a jpg to get client approval. But, knowing that the bulk or actually 99.9% of the actual work will be done in browser, the image is seen as a loss-leader to a degree. I make certain to not overly complicate the image mock up. It's far too easy to overpopulate an image in Photoshop and waste so much time trying to be "pixel perfect" only to hit the hurdle later of the client saying "that doesn't look the same as the image".

I use the image mock up to show basic text placements, sizes and fonts, general color implementation, etc - Basically my image mockups are somewhere between a wireframe and a full comprehensive. I merely want the client to approve color use, placement and sizes. I don't need them to scour the image for any possible imperfections or to ever compare it pixel-by-pixel to the final html/css rendering. I explain all this in the approval processes. I constantly am clear that things will shift and change slightly when we go to live HTML. Thus far, my clients have understood this.