UX Portfolio
  • Experience Design Playbook
  • Case Study: BookUmrah.com
    • Project Brief
    • Research: Expert Interviews
    • Research: Surveys
    • Research: Diary Study & Task Analysis
    • Business Case
    • User Personas
    • Customer Journey Mapping
    • Product Requirement Documentation
    • Information Architecture
    • User Flows
    • Wireframing / Prototyping - Low Fidelity
    • Wireframing / Prototyping - High Fidelity
    • Adaptive & Responsive Design
    • Outcomes & Product Development Future
  • My UX Research Methods
    • Research
    • Diary Studies
    • Task Analysis
    • Content Audit
    • Information Architecture
    • Prototyping / Wireframing
    • Design Systems
    • User Testing
    • Design Sprints
    • Methods of working
    • Docs for Dev teams
Powered by GitBook
On this page

Was this helpful?

  1. My UX Research Methods

Docs for Dev teams

Developer documentation

'Never assume anything' is probably the most important rule when working in any environment. I often work with remote development partners and make a point to over-communicate and provide clear, unambiguous documentation to streamline delivery and keep costs down.

We like to annotate our designs with four critical pieces of information:

What is it? Usually, a brief description of the thing so it can be easily identified.

What does it do? An explanation of its functionality and range of operations

What happens after I've done it? The description of what occurs after the event, process, or result

Does the 'system' need to send something or get something? Technical detail of where information is sent or obtained from, such as text from a CMS, information sent to a database or elements from repositories

PreviousMethods of working

Last updated 4 years ago

Was this helpful?