<abstract> This is an answer I wrote to <a href="https://www.reddit.com/r/web_design/comments/5mm9bi/what_deliverables_do_i_ask_for_from_a_uiux/" source="Reddit" author="loki777coyg">What deliverables do I ask for from a UI/UX designer when starting a webapp project?</a>. </abstract> Ideally, you'd have a VSG (Visual Style Guide) and an Interaction Design. <h>VSG</h> The VSG includes design details like <b>colors</b>, <b>gradients</b>, <b>fonts</b> and <b>standard dimensions</b> as well as details about components/controls, like for icons, properties like, <ul>margins padding separation between label and image alignment of image variants (image to side, image on top) </ul> or for similar properties for controls, like, for example, <ul> buttons tabs list items tooltips callouts flyouts etc. </ul> or even complex controls, like grids, with properties like <ul> where to place icons how to align text how to wrap text are there buttons or a drop-down to manipulate the row etc. </ul> Depending on what you're building, a VSG will include instructions for how components are displayed in different media, like small-screen, responsive, etc. Basically, the VSG is a dictionary with the answer to every question you have about <b>how to style a component</b> in the target platform/technology/media, generally defined in a platform/technology-agnostic way. <h>Interaction Design</h> The Interaction Design includes instructions on how to create UIs using the components defined in the VSG. These are the higher-level rules for <b>how to combine components/controls</b> to build <b>screens</b>. It answers questions about <ul> how to display extra information to the user how to show errors how the user moves between related screens how the navigation history is displayed how the user manipulates data:<ul> auto-save? How/when to validate? How to bulk-edit?)</ul> how the user searches:<ul> auto-suggest? Or enter to show results? How does paging work? Are details shown in-line? </ul> where standard information is displayed where control surfaces are:<ul> Is there a user-login area on-screen? Separate from the main navigation? Or combined? What about content/context-specific actions? What about list-item-specific actions? </ul></ul> Again, this design may also include details on how to adjust compositions/interactions based on the media/context, like small-screen, responsive, etc. Basically, the Interaction Design is a dictionary with the answer to every question you have about how to compose components to represent the <b>screens</b> in <b>workflows</b> and <b>use cases</b>, also defined in a platform/technology-agnostic way. <h>Vs. Reality</h> I deliberately wrote "ideally" above because, often, the specifications you get/have will fall short of this. However, remember that whatever <i>isn't</i> in your specification will have to be decided on-the-fly and ad-hoc and most likely differently in different situations, most likely by the wrong person (the developer). A tooltip is going to have <i>some sort of style</i> even if you don't actually specify it. Unless you're really disciplined---even if you're a one-man team---you're going to end up with noticeable inconsistencies. You'll either have to live with them or invest a lot of time to eradicate them. <h>Better than wireframes/screens</h> The nice thing about working from documents like this rather than wireframes for very specific situations is that it's much easier to build new, unforeseen screens without further help from the designer. That is, instead of having to wait for the designer to make the screen or, instead of just winging it and building the screen based on what you see in other, similar screens, <b>you have a very specific instruction manual on how to style and compose your building blocks to create new screens.</b> Another advantage is that there is a canonical, agreed-upon specification for how things are done to resolve disputes and clarify questions.