Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

A Front-End Developer’s Ode To Specifications

In the physical world, no one builds anything without detailed blueprints, because people’s lives are on the line. In the digital world, the stakes just aren’t as high.

It’s called “software” for a reason: because when it hits you in the face, it doesn’t hurt as much. No one is going to die if your website goes live with the header’s left margin 4 pixels out of alignment with the image below it.

But, while the users’ lives might not be on the line, design blueprints (also called design specifications, or specs) could mean the difference between a correctly implemented design that improves the user experience and satisfies customers and a confusing and inconsistent design that corrupts the user experience and displeases customers.

Further Reading on SmashingMag: Link

For those of us who create digital products, design specs could mean the difference between efficient collaboration and a wasteful back-and-forth process with costly implementation mistakes and delivery delays. It could also mean the difference between your business making money and losing money, in which case lives might actually be on the line.

In short, specs can help us to build the right product more quickly and more efficiently.

What Are Blueprints (And Why Are They Blue)? Link

Why are blueprints blue? To find the answer, let’s go back in time a bit, courtesy of Wikipedia4:

“A blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry. The blue-print process was characterized by light colored lines on a blue background, a negative of the original.”

Architectural blueprints were the photocopier of the 19th century. They were the cheapest, most reliable technology available to copy technical drawings.


Architectural drawing, Canada, 1936 (Image: Wikipedia6) (View large version7)

Blueprints were created by sending light around an ink drawing on transparent film. The light would shine through everywhere except the ink and hit a paper coated with a light-sensitive material, turning that paper blue. This outlined a white copy of the engineering drawing on a dark-blue background.

These copies were then distributed to builders who were responsible for implementing the designs in those drawings.

Today, many graphic designers also distribute design specs to the front-end developers who are responsible for implementing the designs. Design specs are no longer made with paper and light, and they are no longer blue, but, as before, they ensure that the product gets built correctly.

From Bricks To Bits And Bytes Link

I learned the value of architectural blueprints in my previous career as a real estate developer. One of my responsibilities was to find great architects to create blueprints so that the construction workers we hired knew exactly what to build. Somewhere along the way, I realized that real estate development was not for me: I wanted to make a greater impact by building the scalable skylines of the virtual, rather than the real, world. I learned HTML, CSS and JavaScript and went in search of startups that were hiring. My understanding of the importance of detailed blueprints went with me.

In the wild west of World Wide Web startups, I had to build single-page JavaScript applications that looked good and performed well, and I had to do it quickly. Designs were often handed down to us one week before the product’s release date, and we were asked to start sprinting. The designs usually consisted of Photoshop files (PSDs) with a lot of layers and zero specs to accompany them.

For a former real estate developer, working with graphic designs without specs was like getting a set of architectural blueprints with all of the drawings and none of the numbers. Without the necessary CSS “measurements,” I was forced to hunt through layers and sublayers of shapes and text elements to figure out the right HEX value for the border around the “Buy” button or the font family used in the “Forgot Password?” field. Such a workflow was very unproductive.

I was starving for specs when my friend Chen Blume8 approached me with the idea of Specctr189, a tool that would bring the familiar benefits of architectural blueprints to the world of graphic design and front-end web development. I immediately recognized the value and potential of this idea, so we started working together right away, and soon after that, the first version of Specctr was released.


Properties of objects (specs) created with the Specctr plugin (Source: “Blueprints for the Web: Specctr Adobe Fireworks Plugin4610”)

Initially, the Specctr plugin was for Adobe Fireworks users11 only, which at the time — 2012 — seemed to be the best tool for UI and web designers. Later, we expanded the range of supported apps, and today it includes Fireworks, Illustrator, Photoshop and InDesign.

A Picture (And Some Numbers) Are Worth More Than A Thousand Words Link

They say that a picture is worth a thousand words12. Well, a picture and some RGB values could be worth much more!


“One look is worth a thousand words” appears in a 1913 newspaper advertisement for the Piqua Auto Supply House of Piqua, Ohio (Image: Wikipedia13).

The phrase “A picture is worth a thousand words” means that a complex idea can be conveyed with just a single still image. It also characterizes well one of the main goals of visualization, which is to make it possible to absorb large amounts of data quickly. However, in the design and development business, a picture or a single PSD is not enough.

Developers need to know a design’s exact attributes to be able to write the HTML and CSS necessary to recreate the text and shape elements via code. If a PSD is not accompanied by detailed specs, then making approximate guesses or hunting through layers could lead either to errors or the loss of precious development time.

Developer Focus Link

When developing something, I might need several minutes to load the necessary mental models in my head before I can be productive. Any interruption could bring a wrecking ball to the intricate imaginary machinery I’ve struggled to assemble inside my head.

This is why having to look up an RGB value or turn to a teammate to ask which typeface is being used could lead to big gaps in my productivity.

And if you’re a member of a distributed or remote team, then you don’t even have the luxury of immediately getting your questions answered by a colleague — you’re off to an asynchronous communication tool like Skype, Hipchat or, worse, email. As Chris Parnin puts it14:

“The costs of interruptions have been studied in office environments. An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks. Workers have to work in a fragmented state as 57% of tasks are interrupted. For programmers, there is less evidence of the effects and prevalence of interruptions. Typically, the number that gets tossed around for getting back into the ‘zone’ is at least 15 minutes after an interruption. Interviews with programmers produce a similar number.”


This is why you shouldn’t interrupt a programmer. Seriously. (Check the full comic strip15 by Jason Heeris!)

A Carnival Of Errors: Developer Edition Link

Julia had been at her computer for eight straight hours and was late for dinner with her parents, but she had promised to have this CSS transition between the “product” overlay and “buy” overlay on the master branch by the end of the day. She was almost done, but the type on this “Submit” button didn’t look the same as the one that was live on the website now.

“It’s fine,” she thought. “I’ll change it tomorrow.”

Faced with short deadlines and the prospect of rummaging through Photoshop layers, some developers would take a stab in the dark with what type to use — thus, negating the hours of design research they’ve invested with one stress-fueled decision.


The font looks the same. Well, almost.

In the end, we’ll have to redo it anyway, but for now we’ll meet the deadline. It’s all about developer convenience.

No one in the history of forever put in extra effort to do the wrong thing. Mistakes are usually the result of following a tempting shortcut.

The record industry’s failed attempt to halt the digital distribution of music is a good example of this. Spotify’s whole business model16 is based on the fact that “people were willing to do the right thing but only if it was just as rewarding, and much less hassle, than doing the wrong thing.”

Give your front-end engineer a fully spec’ed design and then bask in the rays of gratitude emanating from their face. They’ll get all of your margins and padding exactly right; that subtle gradient will have the precise values you took so long to match; and it will all get done faster. Why would they do anything else? All of the information they need is right there in front of them!

The Triumph Of Tediousness: Designer Edition Link

Lauren took a second to appreciate her finished design. It was well-balanced and conveyed a sense of calmness, all while guiding attention towards the “Submit” button.

She was tired and ready to go home after a long day of work, but she had promised to deliver the finished design so that Julia could get a head start on developing it for tomorrow’s deadline. She sometimes created specs for the developers she worked with, but she just didn’t have it in her to type and draw out each individual annotation “by hand.”

“Julia will figure it out,” she thought to herself as she hit “Send.”

It’s all about designer convenience.

If design specs (i.e. blueprints) have so much to offer, then why aren’t they a part of every designer’s workflow? The reason I, as a developer, might skip looking up the type is the same reason many designers don’t create specs: It’s easier not to.

This is because designers are not using the right tools. They manually measure and draw each dimension, and they type each pixel value and RGB value “by hand,” using the same general-purpose drawing tools that they used to create the design.

Any time you ask an artist to stop creating and focus on process, you’re fighting an uphill battle. The hill becomes dramatically steeper when the process is slow and tedious.

With the right tools to automate the creation of specs, designers can reduce costs and enable their whole team to reap the benefits of creating and distributing design specs.

Let’s Create (And Use) Design Specs Link

The two examples above — with Julia and Lauren — are imaginary, but that doesn’t mean they don’t happen constantly in real life. Developers should not have to make any guesses that lead to errors and lose time. On the other hand, creating detailed specs manually is tedious and takes a lot of the designer’s time.

Is there a better way? I believe there is.

We should start using tools that help us to create design specs with a minimum of hassle. Such tools would save time for both designers and developers and would lead to better designer-developer workflows.

Below are some excerpts from a design document annotated with Specctr. With the help of the Specctr plugin, a designer could quickly provide the color values of any design element, along with the exact width and height, gradient values, type attributes (including font family, weight, kerning, leading, etc.), margins, padding, border properties and more. This would greatly help the developer to implement the design because they would not need to hunt through layers and sublayers or make any guesses.


Text and spacing specs generated with Specctr189 (View large version19)

hape and text specs generated with Specctr (View large version21)

Coordinate and spacing specs generated with Specctr (View large version23)

As a bonus side effect, using detailed design specs will help you to avoid errors and inconsistencies in the final version of the design when it’s implemented in real life. Below is an example of the “drift” that can occur when implementation details are not made explicit and are left up to the developer’s guesswork.


A comparison of how a design can deviate from a designer’s vision without proper documentation: spec’ed design on the left, unspec’ed design on the right. (View large version25)

Note: Specctr is not the only tool that automatically generates detailed design specs. Plugins such as PNG Express26 (designed to work with Photoshop) do similar tasks, but I’ve been mentioning Specctr because I developеd it myself and have the most experience with it. If you have tried other spec-generation tools, please, share your experience in the comments below.

Components And Style Guides Link

Developers have long been familiar with the advantages of breaking a large system down into small components through object-oriented programming27, which is currently the dominant programming paradigm, thanks to the adoption of languages such as Java28. Breaking a complex project into self-contained parts that make up the whole allows a single part to be reused in multiple places in a project and allows for greater project organization and easier maintenance.

Designers are also finding29 that breaking down a design into its atomic components allows for greater efficiency because they’re able to combine them to reuse their code and styles. Seeing the components from which a project’s entire design is derived allows for the immediate communication of style choices made across that project. Examples of the components that would be shown are the grid, buttons, forms, tables and lists.


Grid component from Mozilla’s “Style Guide”31. (View large version32

List component from Mozilla’s “Style Guide”. (View large version34

Components combined with design specs make up a style guide35. A style guide serves as a reference both to communicate a project’s design aesthetic and to provide details of its implementation to developers. Developers no longer have to rely on designers to spec individual documents, and can instead use this reference to find the information they need. In this way, a style guide is another great tool for more efficient collaboration between designers and developers.


A style guide will help you to maintain a consistent look over time. (Source: “How to Make an Effective Style Guide With Adobe Fireworks4537”). (View large version38

Conclusion Link

I reached out to a few designers for comments about the process they follow to document designs. One of my favorite responses comes from Jason Csizmadi, senior visual designer at Cooper39:

“Developers at all stages of projects expect and demand strong documentation.

Although documentation is never the most exciting aspect of design, it’s a critical step in ensuring smooth working relationships, timely delivery and a successful hand-off at the end. Ultimately, design documentation acts as a life-support system, ensuring that your vision is executed properly.”

Like any good business process, design specs should support the primary endeavor — in this case, to create beautiful websites and applications. Creating these products requires collaboration between designers and developers, and effective collaboration requires effective communication. Investing in the development of workflows and tooling around to make this communication easier and more efficient will pay off big with the speed and effectiveness with which products are built and, ultimately, with the success of the businesses that depend on those products.

Further Reading Link

I’d like to thank Michel Bozgounov48, who helped me research this article and made a few useful suggestions to improve it.

(mb, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48

↑ Back to top Tweet itShare on Facebook

Dmitriy Fabrikant is the developer half of the designer-developer partnership that founded Specctr. (UI designers use Specctr to quickly create design blueprints containing the essential type, color, and spacing information developers must have to turn design into beautiful product, all from inside their favorite design tools.) Before stacking bits as a web developer, Dmitriy stacked bricks as a real estate developer. In real estate development no one would dare start construction without a blueprint. Working as a front-end developer Dmitriy saw it happen all the time, often to the project's detriment. That's why when talented designer Chen Blume approached him with the idea for Specctr, he knew they had to build it together. The links for this article were saved and organized using Knovigator. A simple bookmarking tool Dmitriy built to organize the content he liked around the way he searched.

  1. 1

    Or in some cases I give developers documentation and they still don’t follow it. I’ve come to the point where I demand to do all front-end development myself.

    • 2

      That’s because developers just like to whine about never having enough documentation, to justify being late and/or incorrectly implemented. It’s always someone else’s fault.

      From my experience, the best front-end developers work closely with designers from the beginning and ask lots of questions, studies layouts, etc. They generally have an attention to detail that most developers just don’t care about. If you find someone like that, pay them lots of money and treat them well. They are a rare breed!

      • 3

        Cesare Rinaldi

        October 10, 2014 10:39 am

        In my experience I (developer) am generally the one who cares about details, but I guess that I’ve been very unlucky with the designers I’ve worked with. Generally a lot of them come from printed design and they really don’t understand why every single detail is so important when designing for the web (e.g. line height, margins). It’s true, maybe it’s always someone else’s fault, it’s not rare to find a good developer or a good designer, it’s rare to find both in the same office.

        • 4

          vincent visser

          October 16, 2014 12:37 pm

          That’s because companies look at their budget and choose one over the other or hold one in a higher regard than the other.

      • 5

        I am a PHP/Front-end developer and the owner of a digital agency. I would disagree with JJ’s general statement that developers like to whine about lack of documentation and have a lack of attention to detail. There are good developers and there are bad developers just like there are good designers and bad designers. While the statements may be true about bad developers, they are not true about the majority of developers.

        Developers have different objectives than designers. While we (developers) would like to develop the site to the designer’s exact specs, we must also take into consideration the varying constraints of the technologies we’re developing for, best-practices, future-proofing, building efficient code, and developing a manageable application, among other things. All of these things can affect the design. What may look like a lack of attention to design detail may be a focus of attention on something else, (e.g. future-proofing).

        Communication early and often can alleviate many of the issues between designer and developer as each has their own set of strengths and weaknesses (which tend to complement each other). A decent developer will insert himself into the design process from day one and attempt to learn the designers intent. A decent designer will include the developer in some of the design decisions in an effort to better understand the developers constraints.

  2. 6

    And then your perfect 431px gap goes to shit because the design is responsive and that spacing had to be fluid.

    • 7

      Nice article! Although I hear what the previous commenter is saying in that, designers working in web should be thinking in modular and fluid manner, as the web is fluid by nature, it has always been, now we just have loads more screen sizes.

      Learning the basics of html and css may not be a bad idea for a designer working in web either – having a basic understanding of how web pages are constructed reflects in how designs are composited in the graphics software.

      • 8

        Dmitriy Fabrikant

        October 9, 2014 6:25 pm

        Even responsive design requires deciding on dimensions at various screen sizes. Specctr also allows you to specify relative dimensions.

        Regardless of screen size developers still need to know attributes like font, colors, gradients, etc.

  3. 9

    Carefully with those 4 pixels! A sensitive designer could die from heart attack… ;-)

  4. 10

    Arun Sengupta

    October 9, 2014 9:24 pm

    Covered almost all the aspects of the constraints and hurdles … in any designer’s day to day work.
    I do agree to the point that now since we have huge list of screens to cater to … it’s hard to have a single document which covers all the aspects of the design, especially when it’s fluid or responsive … and has to change based on the screen size.
    Now even though I say that … I am sure still the development team requires a full detailed documentation for them to be sure of what each and every element should look like on each and every screen… so that it’s not their fault in the end if the design is not consistent or acc to the perception of the designer, but I don’t blame the developers… and I do agree it helps to have everything listed down and marked up so that the imagination of the designer is well captures and implemented by the dev team and they also don’t complain…but that’s the ideal world :D isn’t it
    It’s always great that the designer has some idea about the code / technology / platform constraints… and the developer has some flexibility in understanding the design aspects and best practices (in some cases latest trends).

    Over all … a very well written article :)

  5. 11

    In addition to developers, testers also may require suitable documentation to be able to sign off their testing. To sign off on UI with no concrete designs to refer to must make testers not sleep at night…

    And re front enders working with designers – this is critical in my experience if the designers have minimal web experience – designers with more print focus cannot understand the nuances of web and so a collaborative effort from the start can avoid a lot of pain and toing/froing during the build process.

  6. 12

    Similar to some other commentators I also ask: How do you completely spec out a responsive design? I’d like to propose that there is no way in which to define a complete blue print without actually writing the code. I mean, what is front end code but the complete spec for the design?

    Designers should code and developers should learn to sit side-by-side with them. If designers gave you complete blueprints, someone else could automate the construction of that page (and as a developer you would offer no value). Developers have a job because they fill in the gaps left behind after the core design is singed off on. They need to put on their designer hats and collaborate with designers when doing the work.

    There is value in making sure that the core design is well defined, and that is a point well made in this article. The core design should cover general direction for color, font, layouts (including responsive). I usually wouldn’t go to the point of pixel distances…let the developer/designer work that out in the final product.

  7. 13

    I studied quantity surveying in school, but I am a front-end developer. I have always been passionate about that. I understand the point Dmitriy is trying to make. A detailed spec from the designer gives the developer less headache and allows full concentration to coding the design. Specs are very important.

  8. 14

    So regarding the specs for responsive design – as I just did that…

    Ever responsive design has its breakpoints where the layouts gets adjusted to a range of resolutions (from 600 to 800 px width the layout is as followed)

    So you have to have a layout for each brakpoint or at least a layout for each breakpoint with significant changes. I always spec the desktop-version of a layout and starting from this I only spec the different elements ( mostly fontsizes, margins) on the following layouts down to the smartphone version.

    Spectre is so an impressive and time-saving tool – thanks for that, really!

  9. 15

    Sorry, but all the instructions in these article seems superfluous. If you are given a design, the build should look just like it, pixel by pixel (with some restrictions), no questions asked. There are a number of tools to help that, for example to overlay the PSD on the browser frame. Every deviation should be apparent without further guidelines.

    If a front-end dev doesn’t deliver exactly similar results just by receiving the same source file, he is simple lazy and unqualified, not uninformed.
    Giving exact properties are rarely effective as PS values more often than not hardly translate to a real browser environment.

    Instructions should only be given for non-static elements/animations, but even without that, a front-end guy could and should implement appropriate derivate designs.

    • 16

      A developer that doesn’t ask questions and push back on design, if necessary, is one that doesn’t care. Developers and designers should be in constant communication during the entire design process and designers should expect pushback on the design if it doesn’t fit within technology constraints or allow the developer to follow best-practices. Simply handing a developer a PSD and the end of the design process and requiring pixel-perfect execution doesn’t lead to quality work.

    • 17

      Patrick Whitty-Clarke

      October 13, 2014 2:03 pm

      Do you get much repeat work from developers? I feel sorry for them.

  10. 18

    How about having a front end dev that also has design skills? Maybe this is a job requirement today, maybe just on smaller projects? The designer should understand and communicate with the dev what it is they are looking for, what’s important, the content. In an rwd era this delivery of a flat photoshop file just doesn’t work, I suppose that’s my “issue” with the article. It was good until I saw the title at a certain x-y coordinate.

    We (devs and designers) need to use the style guide (spec sheet?). Show me some of the core musts (components, colours, fonts, typescale, rigid brand guidelines). Once you abstract the content from the design very interesting things occur.

    So how about this as a process (see how the front-end dev is involved at all points?):

    – Wireframe to show content placement/priority (dev can start to think about frameworks, custom grids, js etc)
    – Draft mockup with styling (dev can finalize some choices made above)
    – Style guide (source your fonts, and colours, setup your sass vars, perhaps build and test some components)
    – Final PSD, with notes about important interactions, and elements (might even be optional if you’re doing the above?)

    If it’s supposed to be pixel/pixel perfect then might i suggest using only the img element. Lightweight on css and html, little bit heavy on the image, wonder what pagespeed would say :)

  11. 19

    As a careful designer I totally understand the needs of a design guide with detailed specs. I’ve been using Specking for long, which I think is clear and straightforward providing nice boxes with needed information. Unfortunetely they don’t provide all I need (the dev guy needs), like alpha, photoshop effects and other minors important things. There’s another tool called Ink, witch provide even more details but has a bad way of show the info. For me, who works with different mobile densities is important to select the an option for the design base (retina, non-retina, MDPI, XDPI, and so on…) to make the proper calculations in pixels.

    Great article by the way. Keep it up!

  12. 20

    Nice one. But Specctr seems to be old, nowadays I somehow feel there should be a tool which generates the CSS or atleast Designers should take up the task of creating css of each visual element, just typing out the Visual part of the CSS. What do you think? Do you know any tool or technique that can do this?

    • 21

      Martijn Hermans

      October 13, 2014 10:36 am

      You would be surprised but Adobe’s CC just released ‘Dreamweaver Extract’. With this “plugin”, you can open up a PSD from dreamweaver and view properties of fonts/images/etc while allowing you to automatically export images by dragging them from design to your code, copying css from fonts, etc.

      I use DW purely as an oversized notepad, so this is actually quite a nice addition. Saves me from switching between PS and DW all the time for specs.

      More info:

      * I’m in no way alligned with adobe or anything, this is merely something that people might have missed and got released about 1 or 2 weeks back.

  13. 22

    Very interesting article.

    In my 14+ years of experience as a Web Designer and as a designer that implements his owns designs in HTML+CSS+JavaScript A.K.A Front End Developer, I’ve never seen a single spec’ed design that had any value let alone done right. At all.

    Going by this image from Specctr, there are clearly many issues here:

    1. Is not Font-Family, is font-family. Or Font family if it’s just a sentence. Is Specctr writing a CSS property? It looks like it. Then write it correctly.

    2. Font-Family: National-Bold. Same issues as in #1. Also, does the designer understand the technical and legal implications of using web fonts? Also, there is no fallback font specified, so the designer is leaving that decision to the Front End Dev. Fine, but don’t complain about it later.

    3. Font-Size: 18 px. Same issues as in #1. Also, there’s no space between the value and the unit. Also, font size 18px is not realistic because if you’re using rems or ems it may not be 18px exactly. In this case, I recommend that the designers use a Modular Scale to define their all their font sizes. – This has revolutionized the way I approach font sizing in my projects.

    4. Color in RGB mode? C’mon, providing the HEX value is way more helpful. I haven’t met the first Front End Dev that deals with RGB for their colors other than doing rgba() when working with opacity, and that’s because you have to use RGB for that.

    5. Text-Align: left align? Same issues as in #1. ALso, it’s text-align: left; not Text-Align: left align.

    6. Line-Height: 36 px. Same issues as in #1 and #3. Also, line-height works better as a unitless property, for scaling reasons. See Eric Meyer’s 2006 article about this:

    7. Letter-Spacing: -0.01em. Is such small kerning really necessary? I bet that if the Front End Dev doesn’t put it in, the designer is not even going to notice.

    8. Font-Style: Normal. Yep, this spec works.

    9. Opacity: 100%. The value of opacity ranges from 0 to 1, without any units. Not from 0% to 100%.

    10. The 23 px and 24 px values. Same issues as in #1 and #3. I’ll just have them be the same, 24px and that’s it. Yet that distance can be relative as well when you’re building responsive, so the designer should understand that although at one resolution the distances will be quite close to 24px, in other resolutions the distances will be different, they will be, of course, proportionate to 24px.

    11. The coordinates, yeah, interesting values but I wouldn’t personally worry about those, they would change on responsive builds anyway.

    12. 351 px. Same issues as in #1 and #3. And as in #11, I wouldn’t personally worry about those, they would change on responsive builds anyway.

    The best spec’ed design someone can create so everyone in the team is happy :), is a design that:

    1. Uses a grid. 12, 16 columns is the norm, if the designer used a different one he should be able to explain why.
    2. If planning to use web fonts then provide all the necessary information about them. Are they free? Does a license need purchased? If so, which web font service offers the web font? Have they cleared the purchasing of the license with their boss or whatever?
    3. Social icons and most plain icons are flat so they can be used as icon fonts or SVGs.
    4. Uses the Modular Scale for all font sizes, and provides the link to the Modular Scale table.
    5. Provides color values in HEX.
    6. Clearly understands that the values in pixels are a mere approximation.
    7. That no design can be translated 100% 1:1.
    8. That browsers and devices will render their design differently.
    9. That it’s absolutely just fine that their design is going to look crappy in IE8 and to some extent in IE9. Let’s not even talk about IE7 or farther back.
    10. That the designer that created the design is learning HTML and CSS right now if they don’t know anything about them.

    I liked #10 the most :)

  14. 23

    Thank you for this article. I (UI/UX Engineer) deal with clients that hand off their designs to us with high expectations and excitement to see it revealed via digital format. I can relate to those poor souls that spend hours digging through unorganized PSD files trying to find the most important information to interpret into code (back in the late 90s – I learned my lesson a long time ago).

    But you know what? I always ask questions up front, no matter how stupid the questions may seem to me. It is ALWAYS better to get the facts before work is done than get several hours down the road and realize you are on the wrong path. And if you can’t get all the facts, use your best judgement on what needs to be done so the user has the best experience possible.

    And if you don’t want to get chewed up and spit out by the client due to your helpful suggestions and user experience expertise, then write out a detailed list of what you did and why. If they realize you spent a lot of time thinking about that to improve their product, they will thank you, if not now, later when their revenues increase.

    Good luck everyone!

  15. 24

    As a designer who first started in print consulting, doing magazine and newspaper redesigns, I consider the specification document to be the most important deliverable in digital designs, rather than a .psd file, for the following reasons:
    1. drawing up a specification is an excellent way to test the design. If it’s too difficult to describe and you end up with too many disparate elements, each requiring their own specs, then you’ve done something wrong.
    2. working through a specification document helps the person implementing the design (whether she’s a typesetter like in the print days, or a developer) to understand the logic of it. This gives the developer the ability to a) structure the project better and b) permit her to deal with issues that may not have been accounted for in way that is consistent with the spirit of the design.

    IMHO specifications are the sine qua non of complex digital design.

  16. 25

    I disagree with your comment about software not hurting. There is plenty of software out there that can kill: life support systems, temperature control systems, defense systems, etc.

  17. 26

    One of the reasons your architects were good designers is that they understood the standards of the building industry. Unfortunately, I have never met a web designer who understood the standards of the browser.

    I accept that there are few accepted standards, but that even makes my terror worse. Not having standards, coupled with not knowing about them, coupled with not trying to follow any … only means that the iceberg is up ahead but nobody’s on watch.

    So they blithely create a set of instructions and restrictions that are so foreign to the environment that, while software developers can do just about anything, the time and cost associated with most implementations of these works of art are onerous and prohibitive.

    I have walked away from many contract opportunities when I saw the front-end designs. I recognized that taking the assignment implied accepting the constraints of design and the expectations that “software development is easy.” (Translation: if I take too long crafting a whole new universe from some hack’s black-hole design I’m the one who will carry the blame, not him/her.)

    One of the more painful periods of our web-developer growth has been in this area of finding standards. Whether it be Twitter Bootstrap or YAML, CSS3 and HTML5, handlebars.js and jQuery and all the rest, the field is still wide open and there may be rules, but there are no standards.

    Unless the designer and the developer both accept the same layouts, tools and even JS libraries as “the current product standards,” the implementation of a design can be an exercise in frustration and nothing more than a web hole into which the owners pour money.

    In brief, specifications are nice. Standards are better. It all makes me want to be a plumber.

    The worst part about some piece of software that prettifies design specifications may be that it can turn a set of horrid expectations into something that looks well-thought-out. This flotsam and jetsam may be accepted by emotional impression rather than by technical rigor. “Oooh. That looks nice. It must be right.”

    Just because a design is “pretty” doesn’t make a single part of it appropriate.

    Hand me that drain snake, will ya?

  18. 27

    Great post! I want to share you a more efficient measurement and design specs plugin for Photoshop & Sketch


↑ Back to top