Skip to content

Styleguide for low-fidelity paper prototyping πŸ“„ and wireframing πŸ“.

License

Notifications You must be signed in to change notification settings

NOALVO/wireguide

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

25 Commits
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

wireguide

Styleguide for low-fidelity paper prototyping and wireframing.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1. Objectives

1.1. These guidelines are supposed to be used by any product owner, manager, designer or developer intended to illustrate visual representations of computer software or internet pages, a.k.a. prototyping or wireframing.

1.2. These guidelines SHOULD be used to represent low-fidelity wireframes, which means that rounded borders, shadows, gradients, images, icons, animations or any complex form of graphics SHOULD NOT be used.

2. Pen πŸ–Š

2.1. SHOULD. Prefer using thin/sharp hydrographic pens or ballpoint pens. Avoid thick pens and markers.

2.2. MUST NOT. Don't use pencils or automatic pencils in order to avoid poor visibility wireframes.

2.3. MUST. Use black, blue, red, green and orange colors to draw elements, attending to the following rules below. When you don't have green or orange color, you MUST replace orange by red and green by black. When you don't have blue, red or black, well... you could not make a comprehensive wireframe.

3. Black elements πŸ–€ Containers

3.1. MUST. Use the black color for general lines, containers and borders. In all, but not limited to, the following cases:

  • Divs
  • Panels
  • Headers
  • Navigation bars (both vertical and horizontal)
  • Menus (tabs, navs, pills, dropdowns)
  • Tables
  • Text
  • Images
  • Modal dialogs

3.2. MUST. For navigation bars, when the bar is prefixed by a trademark or logo, include the word LOGO at the beggining of the bar.

3.3. MUST. Modal dialogs must include close button (Γ—) at the top-right corner.

3.4. MUST. Images must be represented by a square with an x mark touching its corners.

3.5. SHOULD. For tables and general containers that includes repeatable elements, draw only the first line of element and include three vertical dots at the middle of container.

3.6. SHOULD. For tables and general containers that is supposed to be taller than wireframe bounds, DO NOT finish the container with a bottom side line, and apply a three vertcial dashes following each horizontal side of container.

3.7. SHOULD. For tables and general containers that is supposed to be wider than wireframe bounds, DO NOT finish the container with a bottom side line, and apply a three horizontal dashes following each vertical side of container.

4. Blue elements πŸ’™ Features

4.1. MUST. Use the blue color to describe the content, origin and destination of features.

4.2. MUST. Define a reference code for each feature with a letter, starting from A to Z.

4.3. SHOULD NOT. Prefer omiting control labels and instead use the reference code described in 4.2.

4.4. MUST. Build a "Table of Features" including the reference code and the main details of each in a usable free space of the wireframe. If there is no free space in the wireframe, use the back of the sheet to make it.

4.5. MUST. When referencing features in Table of Features specified by item 4.4, use " to describe their labels.

4.6. MUST. When referencing features in Table of Features specified by item 4.4, use β†’ to indicate the destination of the feature, like, but not limited to, opening dialogs and changing pages.

4.7. MUST. When referencing features in Table of Features specified by item 4.4, use ← to indicate the origin of the feature, like, but not limited to, pages e other features, and also the source of labels, like, but not limited to APIs and internal funcions.

5. Red elements ❀️ Modifiers

5.1. MUST. Use the red color to indicate special behaviors of features.

5.2. MUST. Mark read-only, blocked and disabled controls with an "block" sign.

5.3. MUST. Mark elements and controls affected by user roles (privileges elevation) with a (β–³). Elements marked both with 5.2 and this marking will be considered not read-only if the role is satisfied. Indicate more details of the privilege and control behavior in the Table of Features.

5.4. MUST. Mark elements and controls that contains or triggers AJAX loaders with an horizontal three-dot.

5.5. MUST. Mark elements and controls that are repeatable by some iteration with a vertical three-dot. Indicate more details of the iteration in the Table of Features.

6. Green elements πŸ’š Controls

6.1. MUST. Draw input/text boxes with just an horizontal line. DO NOT draw inputs as a rectangle, as they may be confused with a button.

6.2. MUST. Draw buttons as rectangles, including image buttons. For buttons that have a cancel/abort/close behavior include a times character (Γ—) aligned to center.

6.3. MUST. Draw checkboxes as squares with a checkmark inside.

6.4. MUST. Draw radio buttons as circles with a dot inside.

6.5. MUST. Draw dropdown menus writing the "Dropdown" word, followed by a feature reference code (as described in 4.2), and, followed by a black triangle ponting down (β–Ό).

6.5.1. MUST. For the menu panel, draw it as a black container (as described in 3.1), but make a diagonal (northwest to souteast) line at the top-right corner of the container.

6.5.2. MUST. Include an underline at the beggining of each dropdown menu item.

6.5.3. MUST. Include a black triangle pointing right (β–ΆοΈŽ) at the end of each dropdown item which activates another dropdown menu.

6.6. MUST. Put a dashed border at the bottom of hyperlinks.

6.7. MUST. Draw sliders as an horizontal line with a black filled circle on it.

6.8. MUST. Draw switches as two rectancles (one filled and the other not) together.

6.9. MUST. Draw tooltips as rectangles shaped with a left-chevron at the left side.

6.10. MUST. Draw progress bars as two long rectangles (one filled and the other not) together. Place a % inside the white rectangle, as this drawing may be confused with switches.

7. Orange elements πŸ’› Illustrations and layout to be determined

7.1. SHOULD. Draw proposals of text and illustrations that have to be officially determined with the orange color.

8. Grids and browser bounds

8.1. SHOULD. Use simple grids to draw containers and parts of pages.

8.2. SHOULD. Use "browser" grids to draw pages and elements disposed inside a page.

8.3. SHOULD. Use "tablet" and "mobile" grids to represent responsive adjusted desktop wireframes, or, if your wireframe is for a product that focus a specific plaform.

8.4. SHOULD. Use Sneakpeekit to print paper grids described by 8.1, 8.2 and 8.3.

9. Digitalizing

9.1. SHOULD. Use CamScanner to digitalize wireframes, applying "Lighten" or "Magic Color" filter.

About

Styleguide for low-fidelity paper prototyping πŸ“„ and wireframing πŸ“.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published