Do you prepare any specs, guidelines, documentation for your developers? Manually or with which tool?
The prerequisite of this would of-course be a decent to solid understanding of at least HTML and CSS, but this you need anyway if you design for the Web and know its intricacies, and the trade-offs between technical possibilities and limitations, performance, usability and accessibility implications.
You can make such a UI library/style guide together with a developer, any good developer will be happy to help out, and both will profit from learning from each others disciplines.
Thumbs up to all of this. The developers I work with always ask for a UI library/ style guide.
A List Apart has a great article about creating living style guides like these. Coupling design and code into patterns and snippets to be used to across your site, and tying it to a stylesheet in the live or dev environment is really helpful for all involved. It's also quite manageable long-term.
Manually? you crazy? :)
First you should do all your best to persuade the devs and pray to gods so that they do it themselves (have same design tool installed) because it literally kills your soul :). But if you really have to and most of all if the devs don't respect your every single detail go with:
- Sketch Measure (for Sketch)
- Ink Plugin (Photoshop)
Both are free.
I tried Ink before, it's not enough. specking and specctr have many more intuitive features I prefer.
I just started working with some designers that have been making mockups in InDesign, and in it you can establish some type styles and name them individually, so they have gotten in the habit of making a list of styles for things like
p, etct. and in those style they explicitly state the font-size, font-weight, font-style, line-height, and letter-spacing. Those paired with the design file itself have done a pretty good job of answering all of the questions I usually have as a developer, though to be honest, what I'd love is something like style tiles, something with hover-states and interaction considered, though I know interaction is a tricky one that definitely requires some dialog anyway.
I usually use photoshop when I'm handing designs off, but I love indesign. I sometimes use indesign for my designs that I know I'll be coding.
How do the designers hand off the files to you? Native indesign files? Most Devs don't know what to do with indesign. Even though it was made for print, to me, it is a really good web design app. Styles, linked graphics, fluid states, etc.
They usually bundle them into a build package from InDesign that comes with all of the links/assets and fonts, and often they come as a "desktop" design, and whether they specify things or not I'll adapt it to be responsive, but there is room for a lot of improvement there. Sometimes they will do a mockup at a small-screen size too, and sometimes even inbetween, though typically those aren't required except on a minor, module-specific scale that I only discover once I put it together. I think most developers, if comfortable with working with Photoshop, and that's highly likely, would be able to figure out things in InDesign, but I have had experience working with it for print layout in the past, so I might not be a great judge.
I think some things that are really valuable when it comes to handing off design files to developers that aren't as tangible as the actual files they hand off are:
- You actually sit down with the developer and go through the design files to talk about certain parts, and to find out if there are questions right off the bat.
- You make yourself available to talk through issues with the design, and make it known that you are always down to talk through things and open to ideas.
I work with some amazing designers, but even they typically leave out one or two things, or forget to consider some web-specific issue that their design might bring up that as a developer I might be able to recognize more easily, so being able to talk through those things on-the-spot, ideally even before the design is "finalized" is extremely helpful.
Great comments all around - but most come from the designers perspective (which granted is the question I realize). As a developer figured I'd give my two cents about what makes my life easier, and ultimately helps me build what the designer created, without losing the details.
To take a design to code I like to have 2 things: 1. Global Spec Sheet (style tile, UI library, whatever you call it) I've found that a spec sheet gives me a lot of the good basics, but can be limited to: - Font family, line-height, weight for H1, H2, and p - Hex and RGB for the main colors - any special notes on active states, hovers, animations ect.
- An asset file of all the images used, sized and web-optimized (named something that helps me know where it goes)
Then with those two things in hand, I'll open up the design in Photoshop and measure padding, spacing, alignments, ect. aka anything I need to get specifically right as I'm going along. (I recognize that not every dev wants to do it, but its been effective for me)
After the first pass is finished - call it prototype1 - I send it back over to the designer to correct for details, or anything else that looks off now that its in code rather than photoshop. That puts us into an iteration cycle that ultimately leads to a final product we're both happy with.
Communication and knowing each others craft is key for our team and helps smooth out any bumps or rough patches along the way.
You should try Markman.
This is going to sound a bit crazy, but I often don’t spec for positioning at all. I do usually give view/pane/section sizes, but not for element positioning.
I’m going to have to measure the mock vs the app anyway, so it’s common for us to just throw things into place, then I’ll provide adjustments to nudge everything into perfect place. It’s really quick, and doesn’t require unneeded work.
This is just for positioning. I do provide font specs and colours. Colours are often as code so the dev can just import them directly with no additional work.
If you're a perfectionist, which I consider myself being, I don't trust anyone else with doing the front-end development of my created design/UI/mockup.
Really. You/Me/Us as a designer only care about the fine details. Why? Because details make a difference. Details define the end work. Details is what makes a design stand out from the other 99%.
Till today, I haven't found any core-developer caring for such details. So my advice is: Learn to code! JS / (S)CSS/ HTML.
You need to work with more people then.
Perhaps. I'm only speaking on my own experiences. I'd love to work with people who do care about the details. Less work for me!
It's really nice, but I wouldn't say less work. Just as much work collaborating with the front-end dev on interactions and design elements. However, at least someone cares enough about getting the design right in the browser as you do in crafting the design from scratch.
Yeah, I can imagine that must be nice when you're able to work with someone like that. I think with 'less work' I really meant to say 'Feeling like someone also cares and is willing to go for the same (perfectionist) result'.
Sketch Measure helps a ton, some stuff I do manually in Sketch. Every time I create one of those a part of me dies inside.
Sketch Measure and front-end style guides, that I tend to prepare by myself, since I know how to do front-end stuff and it's just way easier then.
A nice pdf of all the elements specifications
I used to do big handoffs--but then I'd always thing of "just one more thing" to change, and the developer would have a couple great ideas, and the scope would change, and my big fancy handoff would be out of date before I knew it.
Now I try to work alongside developers as much as I can.
- Before development, I'm in my UX phase. Who are our users? What do they want to accomplish? How does this fit together on the high level? If I have a handoff at all, it'll be a few requirements, personas (sometimes), some modelling, etc. No UI, no colors, no type yet!
- During development, I answer questions as they come up and sketching side-by-side with developers. They build UI based off of quick sketches, and we validate our assumptions using real code as soon as we can.
- When it's time to wrap up and add polish, I give them marked up screenshots with colors, type, spacing, etc--or, more likely, just dive into code and tweak it myself.
Keep in mind this is a product workflow in a startup (not agency work) and for better or worse we often hack on new projects on web first (vs iOS/Android).
If using photoshop - I use CSSHat and build the page myself in HTML/CSS
if using sketch, i use sketch measure plugin.
Some may not agree (even in my organization), but I think design should own the presentation layer so as to minimize churn.
I have to spec things manually
Plugins or any automated tool will never be enough... You need to have your own methodology for the web, and for native mobile apps as well.
The best way to deliver specs / assets / IxD's to developers, is to first, have them fully understand the concept and get them excited about it.
second, prepare a detailed PDF with everything they need. ( colours, spaces, fonts, animations, transitions etc... ) this is the part you define your Design pattern.
Once they'll combine the first and the second - the communications will be in best shape to proceed with implementation and support it at any point.
We create a UI kit (style title) full of reusable elements along with client comps, but use keynote for a usability guide as well as regular conversations (sprint talks). UX designer and dev are always in constant communication. If and only of the front end dev is not the designer.
Haven't found a great way yet – since devs usually are on linux they can't (easily) use Keynote, Sketch or Photoshop.
I create an all-stuff PSD with all states of buttons and elements. Also, I know very well frontend development and I can tell developers anything they need about effects, transition, etc.
I use specking for full sepcs and pen + paper for quick ideas :)