reustyle 2.0.7

data/styleguide/content/design/validating-designs.tpl

@@ -0,0 +1,304 @@
+---
+name: Usability testing
+---
+<!-- Index -->
+
+<ul class="table-of-contents">
+  <li><a href="#no-validation">When don't we need user validation?</a></li>
+  <li><a href="#validation">When do we need user validation?</a></li>
+  <li><a href="#testing">How to test</a></li>
+</ul>
+
+<!-- Intro -->
+<p>Usability testing can be used to establish problems that need solving, validate a hypothesis or to test a solution. Depending on what's required, there are different types of testing availability.</p> 
+
+<p>However, not every change needs to be tested. This page is deisgned to highlight when should and shouldn't use testing, and how we should do it when we do.</p>
+
+<!-- When don’t we need validation of our designs? -->
+<div class="us-content-group">
+  <a id="no-validation"></a>
+  <h2>When don’t we need validation of our designs?</h2>
+  <p>Plenty of design changes don’t require upfront hypothesis validation. If the design change is due to any of the following it may not need validation from users:</p>
+  <ul>
+    <li><a href="#Site-consistency">Site consistency</a></li>
+    <li><a href="#Design-conventions">Design conventions</a></li>
+    <li><a href="#Usability-conventions">Usability conventions</a></li>
+    <li><a href="#External-requirements">External requirements</a></li>
+  </ul>
+
+  <a id="Site-consistency"></a>
+  <h3>Site consistency</h3>
+  <p>Colour, font, shading, button types, and anything in uStyle is a given. We want to achieve site consistency for brand reasons.</p>
+  <p>Functionality, UI, hierarchy are not 'look and feel' consistency.</p>
+  <h4>Example</h4>
+  <p>Moving the first two Broadband designs ('Oldest stlye' and 'Old style') to be more ‘in line’ with the third design ('New style') is an on-going project of consistency.</p>
+  <p>Changing the colours of the first design or moving to a consistent layout would not require testing.</p>
+  <p>Similarly, changing the row-data presentation in the second example to be more consistent with the third example would not require testing.</p>
+  <div class="us-grid-row">
+    <div class="us-col-md-6">
+      <i>Oldest style</i><img alt="image" class="us-img--full trailered" src="/images/site-consistency01.png">
+      <i>New style</i><img alt="image" class="us-img--full trailered" src="/images/site-consistency03.png">
+    </div>
+    <div class="us-col-md-6">
+      <i>Old style</i><img alt="image" class="us-img--full trailered" src="/images/site-consistency02.png">
+    </div>
+  </div>
+
+  <a id="Design-conventions"></a>
+  <h3>Design conventions</h3>
+  <p>There are certain web-design standards, and in our aim for a consistent user experience, maintaining web consistency is an important part of that.</p>
+  <p>The following is a non-exhaustive list of design conventions:</p>
+  <ul>
+    <li>Logos top (left) and links to HP</li>
+    <li>Navigation is top of the page</li>
+    <li>Text links are blue (pre-click)</li>
+    <li>Buttons link to stuff (affordance)</li>
+    <li>Icons (search)</li>
+    <li>Visual hierarchy</li>
+    <li>Search (top right)</li>
+    <li>Clickable form fields</li>
+  </ul>
+  <h4>Example</h4>
+  <p>A basic UI convention is the distinction between active elements and inactive elements, with inactive elements being 'greyed out'.</p>
+  <p>The below car insurance has an overlay that must be interacted with to continue with the page below, but only part of the page is greyed out.</p>
+  <p>Five clickable elements on this page aren’t greyed out, despite not being clickable:</p>
+  <div class="us-grid-row">
+    <div class="us-col-md-6">
+      <img alt="image" class="us-img--full trailered" src="/images/design-conventions.png">
+    </div>
+  </div>
+
+  <a id="Usability-conventions"></a>
+  <h3>Usability conventions</h3>
+  <p>The <a href="https://www.nngroup.com/articles/ten-usability-heuristics/">ten basic usability heurisitcs</a>, like basic design rules, give us a number of usability principles that must be sense-checked against. Designs that do not meet these requirements give us a clear problem to be solved without the requirement of validation. </p>
+
+  <h4>Visibility of system status</h4>  
+  <p>Keep users informed about what is going on through appropriate feedback within reasonable time. In the example below the user cannot see what impact selecting a dropdown option has because the overlay covers the results table:</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-8">
+         <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-visibility.png">
+            <p>
+             <i>"Did updating those filters do anything?"</i>
+            </p>
+        </div>
+      </div>
+    
+  <h4>Match between system and the real world</h4>
+  <p>Speak the users' language with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-4">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-real-world.png">
+            <p>
+              <i>"Large as in size of people or house? Doesn’t it depend what they’re doing? What’s a Plusnet safeguard?"</i>
+            </p>
+        </div>
+      </div>
+    
+  <h4>User control and freedom</h4>
+  <p>If a user makes a mistake, let them undo, redo, go back, etc...</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-10">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-freedom.png">
+            <p>
+              <i>"I wanted more details...and now i've left the site....how do I get back?”</i>
+            </p>
+        </div>
+      </div>
+    
+  <h4>Consistency and standards</h4>
+  <p>Users should not have to wonder whether different words, situations, or actions mean the same thing.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-8">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-consistency.png">
+            <p>
+              <i>"Is a plan and a tariff the same thing?”</i>
+            </p>
+        </div>
+      </div>
+  
+   <h4>Error prevention</h4>
+   <p>Even better than good error messages is a careful design which prevents a problem from occurring in the first place.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-8">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-error.png">
+            <p>
+              <i>"No deals, why did you present it as an option?"</i>
+            </p>
+        </div>
+      </div>
+    
+    <h4>Recognition rather than recall</h4>
+    <p>Minimise the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part to another.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-4">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-recognition.png">
+            <p>
+              <i>"I’ve filtered these results, but by what?"</i>
+            </p>
+        </div>
+      </div>
+    
+    <h4>Flexibility and efficiency of use</h4>
+    <p>llow users to tailor frequent actions. 1-button checkout via Amazon, or Add to my wishlist via Airbnb.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-8">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-flexibility.png">
+            <p>
+              <i>"I personalised all these details yesterday, why has it just reverted?"</i>
+            </p>
+        </div>
+      </div>
+    
+    <h4>Aesthetic and minimalist design</h4>
+    <p>Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-6">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-minimalist.png">
+            <p>
+              <i>"What am I supposed to do on this page?"</i>
+            </p>
+        </div>
+      </div>
+    
+    <h4>Help users recognise, diagnose, and recover from errors</h4>
+    <p>Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.</p>
+      <div class="us-grid-row">
+        <div class="us-col-md-6">
+          <img alt="image" class="us-img--full trailered" src="/images/ux-conventions-errors.png">
+            <p>
+              <i>"Ahhhh....the ol' requested format..."</i>
+            </p>
+        </div>
+      </div>
+    
+    <h4>Help and documentation</h4>
+    <p>Any such help information should be easy to find, focused on the user's task, list concrete steps to be carried out, and not be too wordy.</p>
+
+  <a id="External-requirements"></a>
+  <h3>External requirements</h3>
+    <p>Sometimes design is dictated - commercial or regulatory or business.</p>
+    <p>If there is flexibility around how these are implemented we can enter the design process. Sometimes there isn’t though, and they have to be implemented.</p>
+    <h4>Example</h4>
+      <div class="us-grid-row">
+        <div class="us-col-md-6">
+          <img alt="image" class="us-img--full trailered" src="/images/external-requirements.png">
+            <p>
+              <i>"The brand red clashes with this provider's red."</i>
+            </p>
+        </div>
+      </div>  
+</div>
+
+
+<!-- When do we need validation of our designs? -->
+
+<div class="us-content-group">
+  <a id="validation"></a>
+    <h2>When do we need validation?</h2>
+    <p>If our change isn’t down to one of the above then it’s problem solving, so we need to structure our approach to design differently - we  need to <strong>understand the problem</strong> first.</p>
+      
+    <h3>Symptoms not problems</h3>
+    <p>A problem statement is the design brief, but first we need a good problem.</p>
+    <p>Data tells us about results, not causes. It tells us that it looks like there is a problem, but now what the problem is. Data comes from:</p>
+    <ul>
+      <li>GA</li>
+      <li>Fullstory</li>
+      <li>Crazyegg</li>
+    </ul>
+    <p>Similarly business objectives are things we desire to happen. They tell us what we want to the outcome to be. Objectives sound like:</p>
+    <ul>
+      <li>Increase conversion by…</li>
+      <li>Reduce drop out by…</li>
+      <li>Stop people bouncing on…</li>
+      <li>Stop people clicking out on…</li>
+      <li>Get people to click on…</li>
+    </ul>
+    <p>These tell us there is a problem, but we don’t know what it is.</p>
+    <p>A real problems is something we’ve observed a significant number of occasions.</p>
+
+    <h3>How to define the problem</h3>
+    <p>Testing designed to steer design, or validate assumptions about what problems users are encountering, is known as ‘formative’ testing. It’s open-ended, and the tasks are simply to run a comparison, or to go through a journey start to finish.</p>
+    <p>Any type of testing, whether it be face-to-face, guerilla, remote, or interviews, can help define the problem. This allows us to frame the problem with a problem statement. A problem statement is:</p>
+    <blockquote>A concise description of the issues that need to be addressed - it is specific, measurable and explains what it impacts. There are no assumptions or solutions.</blockquote>
+
+    <h3>Only with a problem can you design a solution</h3>
+    <p>Once the problem is clearly defined, start trying to solve it (one problem at a time), but remember to validate the solutions as soon as possible.</p>
+    <p>'Summative' usability testing can help validate. Summative testing gives the user a particular task to complete that tests the solution against the problem. Again, any type of testing can perform this function.</p>
+
+    <h3>But wait!</h3>
+    <p>User testing is great to validate flows, designs and interactions, but it's not exhaustive. There might be bugs, or solutions that don't work in certain scenarios. This is where in-house testing and the device lab comes in.</p>
+</div>
+
+
+
+<!-- Testing -->
+
+<a id="testing"></a>
+<div class="us-content-group">
+  <h2>How to test</h2>
+  <p>So what type of testing should we use, and when?</p>
+  <a href="https://www.nngroup.com/articles/which-ux-research-methods/">This article by Nielsen Norman Group</a> is a great starting point to understand testing methods and when to apply each.</p> 
+  <p>There are over 20 types of validation, including quant methods, but here at uSwitch we predominantly use the following:</p>
+  <ul>
+    <li><a href="#interviews">Interviews</a></li>
+    <li><a href="#face-to-face">Face-to-face usability testing</a></li>
+    <li><a href="#guerilla-testing">Guerilla testing</a></li>
+    <li><a href="#in-house-testing">In-house testing</a></li>
+  </ul>
+  
+  <a id="interviews"></a>
+  <h3>Interviews</h3>
+  <p>Interviews are designed to understand behaviours, needs and pain-points around a particular task.</p> 
+  <p>They are open-ended and can help define design personas - archetypes that can be used as a reference point for any design changes for that product.</p>  
+  <h4>How</h4>
+  <p>See the interview checklist</p>
+  <h4>When</h4>
+  <p>Interviews are most commonly used at the earliest stage of product development to determine the needs/problems that the product will address.</p>  
+
+  <a id="face-to-face"></a>
+  <h3>Face-to-face usability testing</h3>
+  <p>Face-to-face testing can be used in a formative or summative sense, and can be combined with an interview and simple exercises, like card sorting.</p>
+  <p>This is the highest-fidelity form of validation. The feedback you receive   will be of the highest quality, but it will also take you the most time.</p> 
+  
+  <h4>How</h4>
+  <p>Face-to-face testing consists of preparing a particular task, putting it in front of real users, and seeing how they get on.</p> 
+  <p>As it’s face-to-face, you can also interview users in this format, or ask them to complete exercises such as:</p>
+  <ul>
+    <li>Product Reaction Cards - Used to determine how desirable a product or process is</li>
+    <li>Unmarked Semantic Differential Scales - Used to understand reactions to particular words and phrases</li>
+    <li>Card sorting - Used to understand hierarchy of importance, or expected flows</li>
+  </ul>
+  <p>See the testing checklist for a step-by-step guide to setting up and running a test. The most crucial components are:</p>
+  <ul>
+  <li>Goals - What are you trying to achieve?</li>
+  <li>Tasks - Every task you ask a user to complete should answer a question you need answered. Formative testing on an exisiting product will have open-ended goals, whereas tasks designed to test a solution should be specific.</li>
+  <li>Test plan - Script, scenario, tasks, participants, questions, anything the moderators needs. Write it all down so you have it to hand during the test.</li> 
+  <li>Test the test - Something will go wrong, promise, so test it first.</li>
+  <li>Get your team involved - There's nothing like seeing your solution fail first hand.</li>
+  </ul>
+  <h4>When</h4>
+  <p>Anytime. For an existing product where the objective is to discover problems, an open-ended test asking users to complete the most common journey. This should be done at least once a year.</p>
+  <p>For a new product or feature face-to-face testing is always a good idea. The objective here is to <strong>test the solution against the problem</strong> using particular tasks.</p> 
+
+  <a id="guerilla-testing"></a>
+  <h3>Guerilla testing</h3>    
+  <p>A lower-fidelity version of face-to-face testing, guerilla testing sacrifices quality for speed. The feedback you receive will be of lower quality as the participants may not fit user types, and the testing environment is more ‘ad-hoc’ (think coffee shops, sandwich places).</p>
+  <p>Just like face-to-face testing, guerilla testing involves preparing a particular task, putting it in front of real users, and seeing how they get on. You can also do interviews and get quant feedback but again, the feedback will be lower quality.</p> 
+  <h4>How</h4>
+  <p>See the guerilla testing checklist for a step-by-step guide to setting up and running a test.</p>
+  <p>The number of participants should be at least 5 for guerilla testing, but you can use your discretion.</p> 
+  <h4>When</h4>
+  <p>Guerilla testing is perfect at the early stage of a design, when you want to sense check a particular flow, component, or wording.</p> 
+  <p>Any fidelity of design can be used. Guerilla testing works best when kept relatively informal, and the participant feels at ease.</p>
+  
+  <a id="in-house-testing"></a>
+  <h3>In-house testing</h3>
+  <p>Asking your colleagues in the office for feedback. This is the quickest but lowest quality form of validation.</p>  
+  <p>Like guerilla testing this is an informal type of testing, but the quality is considerably lower owing to familiarity with the product, bias based on personal relationships and a mismatch between persona types and testers.</p> 
+  <p>In-house testing is perfect for bug testing, seeing if anyone can ‘break’ your design, and last-minute tweaks. It is not for designed to surface flow or interaction changes.</p> 
+  <h4>How</h4>
+  <p>See the bug-testing checklist</p>
+  <h4>When</h4>
+  <p>A few days before release</p>   
+  
+</div>

data/styleguide/content/index.tpl

@@ -0,0 +1,51 @@
+---
+template: simple.tpl
+name: uSwitch living styleguide
+---
+<p>
+  The sum of our efforts towards style guidelines, a pattern library and an automated front-end. Made with &#10084; at <a href="https://www.uswitch.com" target="_blank"><strong class="us-color--blue">uSwitch.com</strong></a>
+</p>
+<div class="us-content-group mobile-bordered">
+  <div class="us-grid-row">
+    <div class="us-col-md-6">
+      <h3>Design guidelines</h3>
+      <p>uStyle includes documentation and guidelines relating to our core design principles. It is where we document everything that happens within our brand, UX and front-end development.</p>
+    </div>
+    <div class="us-col-md-6">
+      <h3>Automated development</h3>
+      <p>uStyle is a gem, a bower package, a npm package and static assets. This allows our team setup to choose how they wish to implement the core front-end of uSwitch. We've tried to be as accessible as possible.</p>
+    </div>
+  </div>
+</div>
+<div class="us-content-group mobile-bordered">
+  <div class="us-grid-row">
+    <div class="us-col-md-6">
+      <h3>Pattern library</h3>
+      <p>At its core, uStyle is a pattern library. It contains all current components and elements of the uSwitch UI. These are documented in the <a href="/pattern-library/">pattern library</a> section.</p>
+    </div>
+    <div class="us-col-md-6">
+      <h3>Designer + developer happiness</h3>
+      <p>Delivering designer + developer happiness is very important to us. uStyle provides a base for all our design and development work and allows our designers and developers to focus on the things that matter, whilst making their lives easier when prototyping.</p>
+    </div>
+  </div>
+</div>
+<div class="us-content-group">
+  <h2>The logo</h2>
+  <div class="us-grid-row">
+    <div class="us-col-md-2">
+      <svg class="us-icon--large us-icon--ustyle" role="img">
+        <use xlink:href="/images/icons.svg#icon-ustyle"></use>
+      </svg>
+    </div>
+    <div class="us-col-md-10">
+      <p>There is no reason for this logo other than it's funny and unicorns are all the rage just now.</p>
+
+      <p><strong>Disclaimer:</strong> uSwitch is not a unicorn company.
+    </div>
+  </div>
+</div>
+<div class="us-content-group">
+  <h2>We're looking for great talent</h2>
+  <p>Want to help us build more things like uStyle? We're constantly trying to deliver a better experience for customers and developers, and we're looking for passionate people to join our team.</p>
+  <p>Fire us an email at <a href="mailto:jobs+developer@uswitch.com">jobs@uswitch.com</a> with your CV and tell us a bit about yourself.</p>
+</div>

data/styleguide/content/language/grammar.md

@@ -0,0 +1,220 @@
+---
+name: Style
+---
+
+The smallest mistake can undermine the biggest (and most important) of messages. Those writing for uSwitch should ensure they follow these style rules that cover everything from headlines to hyphens, and numbers to names.
+
+<ul class='table-of-contents'>
+<li><a href="#Abbreviations">Abbreviations</a></li>
+<li><a href="#Acronyms"> Acronyms</a></li>
+<li><a href="#Ampersand">Ampersand</a></li>
+<li><a href="#Apostrophes">Apostrophes</a></li>
+<li><a href="#British English">British English</a></li>
+<li><a href="#Bullet points">Bullet points</a></li>
+<li><a href="#Capital letters">Capital letters</a></li>
+<li><a href="#Company names and references">Company names and references</a></li>
+<li><a href="#Contractions">Contractions</a></li>
+<li><a href="#Dashes and hyphens">Dashes and hyphens</a></li>
+<li><a href="#Dates">Dates</a></li>
+<li><a href="#Full stops">Full stops</a></li>
+<li><a href="#Government">Government</a></li>
+<li><a href="#Legals, disclaimers and caveats">Legals, disclaimers and caveats</a></li>
+<li><a href="#Less vs. Fewer">Less vs. Fewer</a></li>
+<li><a href="#Numbers">Numbers</a></li>
+<li><a href="#OK">OK</a></li>
+<li><a href="#Percentages">Percentages</a></li>
+<li><a href="#Plans vs tariffs">Plans vs tariffs</a></li>
+<li><a href="#Quotation marks">Quotation marks</a></li>
+<li><a href="#Titles and Names">Titles and Names</a></li>
+<li><a href="#Wi-Fi">Wi-Fi</a></li>
+</ul>
+
+<span id="Abbreviations"></span>
+**Abbreviations**
+
+For names of companies or organisations, if an abbreviation is more familiar than the full form (e.g. BBC, IBM) use that. If not, write the name in full the first time you mention it, followed by the abbreviation in brackets. The next time you refer to it, use only the abbreviation.
+
+<span id="Acronyms"></span>
+**Acronyms**
+
+Write out in first use, noting the acronym in brackets; then use just the acronym going forward. Familiar acronyms such as WiFi, HTML, HMRC and BT are exempt from this rule.
+
+<blockquote>
+	The TaxPayers’ Alliance (TPA) has warned that the campaigns being led by lobbies could lead to higher household bills. Matthew Sinclair, director of the TPA ... 
+</blockquote>
+
+<span id="Ampersand"></span>
+**Ampersand**
+
+Do not use the “&” symbol unless it is part of a company or product name.
+
+<span id="Apostrophes"></span>
+**Apostrophes**
+
+Avoid common misuse of apostrophes:
+
+- Mixing up it’s (it is) and its (possessive)
+- Using to denote plural: DVD’s (wrong) vs DVDs (correct)
+- When writing Dos and Don’ts (not Do’s and Don’ts)
+- When writing decades 1990s (not 1990’s); the ’80s (not the 80’s)
+
+<span id="British English"></span>
+**British English**
+
+Use the British ‘s’ in words such as ‘realise’, and ‘specialise’, rather than the American ‘z’.
+
+<span id="Bullet points"></span>
+**Bullet points**
+
+Bullet points are a good way to make web copy easier to scan for readers. Bullet points should always be round, and limit bullets to six or fewer. Make  sure they are grammatically logical.
+
+<span id="Capital letters"></span>
+**Capital letters**
+
+Never use all capital letters. Headlines follow usual sentence structure, with only the first word and proper nouns utilising capitals.
+
+<span id="Company names and references"></span>
+**Company names and references**
+
+Follow punctuation and capitalisation of company names and products as they are branded.
+
+<blockquote>
+	E.ON, iPhone, iSaver
+</blockquote> 
+
+When referencing a company in a news or guide, remember to always keep them in the singular.
+
+<blockquote>
+	BT is launching a new ... (not BT are launching a new ...)
+</blockquote>
+
+<span id="Contractions"></span>
+**Contractions**
+
+Our tone of voice is friendly and familiar, so it’s fine to use contractions like ‘they’ll’, ‘it’ll’, ‘isn’t’.
+
+<span id="Dashes and hyphens"></span>
+**Dashes and hyphens**
+
+If you use a dash within a sentence to create emphasis, then use a long em dash – rather than a hyphen (-).
+Compound adjectives before a noun generally use a hyphen (e.g. ‘the well-organised energy provider’). After a noun, they should be separated (e.g. ‘the energy provider was well organised’).
+
+<span id="Dates"></span>
+**Dates**
+
+Always write out the date, using day, month, year format in news and guides: 
+
+<blockquote>
+	9 December 2013. When using dates in tables, this may be shortened for space reasons to 9/12/13
+</blockquote> 
+
+In forms when asking for a date we always use the DD/MM/YYYY format.
+
+<span id="Exclamation marks"></span>
+**Exclamation marks**
+
+Use sparingly, never in headers or intro copy, best suited for marketing/promotional material or news/blogs. 
+
+<span id="Full stops"></span>
+**Full stops**
+
+Don’t use full stops at the end of headlines.
+
+<span id="Government"></span>
+**Government**
+
+Do not capitalise unless starting a sentence. The abbreviated Gov’t can be used in headlines and desk heads/straplines. 
+
+<span id="Legals, disclaimers and caveats"></span>
+**Legals, disclaimers and caveats**
+
+Superscript numbering should be used when there is more than one caveat, however, when there is only one caveat in a communication, an asterisk (*) should be used.
+
+<span id="Less vs. Fewer"></span>
+**Less vs. Fewer**
+
+Use “less” when the subject is something that cannot be counted
+
+<blockquote>
+She wants to have less clutter on her desk.
+</blockquote>
+
+Use “fewer” when the subject is something that can be counted
+
+<blockquote>
+He sent fewer texts after getting a £100 phone bill.
+</blockquote>
+
+<span id="Numbers"></span>
+**Numbers**
+
+- Numbers nine and below must be written out: one, two, three, etc. 
+- Numbers 10 and higher use numerals: 15, 67, 987, etc.
+- Spell out any amount when it starts a sentence: Three hundred and twenty customers surveyed said they had been wrongly billed on more than 15 occasions. 
+- Use commas with figures 1,000 and above. 
+- With million and billion, write out in body copy; the abbreviation (£43bn) is acceptable in news headlines for space reasons.
+- Always use numerals when using the “£” or “%” symbols
+
+<span id="OK"></span>
+**OK**
+
+Not Ok or okay.
+
+<span id="Percentages"></span>
+**Percentages**
+
+Always use the “%” symbol; only use “per cent” at the start of a sentence. Always use numerals when talking about percentages (54%), unless it starts a sentence. We never use abbreviation “pc” when talking about percentages.
+
+<blockquote>
+	Fifty-five per cent of the population own an iPhone.
+</blockquote>
+
+<blockquote>
+	Of those surveyed, 55% said they had been denied a credit card. 
+</blockquote>
+
+<span id="Plans vs tariffs"></span>
+**Plans vs tariffs**
+
+Plans is the preferred term, only switch to use of tariff when trying to avoid repetition within one email or guide.
+
+<span id="Quotation marks"></span>
+**Quotation marks**
+
+Always use double quotation marks (“) when placing a direct quote in body copy.
+
+Use single quote marks (‘) in headlines, standfirsts/dek heads and when quoting within a quote:
+
+<blockquote>
+	Super-fast broadband uptake ‘reaches 20% in UK’
+</blockquote> 
+
+<blockquote>
+	“Super-fast broadband will be the engine for growth for the broadband future of Britain," he said. 
+</blockquote> 
+
+<span id="Titles and Names"></span>
+**Titles and Names**
+
+Professional titles are not capitalised unless it directly precedes a name:
+
+<blockquote>
+	Director of Consumer Policy Jane Smith said that the news was a shock.
+</blockquote>
+
+<blockquote>
+	Jane Smith, director of consumer policy at the company, said the news came as a shock.
+</blockquote>
+
+On first reference, use the person’s first and last name. On subsequent references, last name only is used. 
+
+Mr/Mrs/Miss/Ms is never used.
+
+<blockquote>
+	Energy Secretary Ed Davey was on-hand to field questions about the news. Davey arrived late, citing a long-running meeting.
+</blockquote>
+
+<span id="Wi-Fi"></span>
+**Wi-Fi**
+
+Not wifi, WIFI, WiFi, etc.