Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Start high-level requirements analysis. Document your findings in the Project Confluence (and for documents in the project folder). Keep it short and light, the The goal is to learn and get an overview, not to write a requirements document. However you can document high level requirements you encounter in the section "High level requirements" on the Extended User story mapping template (TODO: link to this page when added). Also for point d. Competitor Analysis you should document what you found, in the confluence section "Feature Discussions" on the page related to this theme (TODO: add a section for links to relevant feature discussions to the user story mapping template) 
    1. Top-down requirements analysis (coming from above you in a hierarchy, long-term vision and goals, or laws, etc). Gather, discuss and study:
      1. Relevant company goals or OKR's
      2. Product Vision, Product KPI's, Persona.
      3. Roadmap Theme and Requirements already gathered during Roadmap theme preparation.
      4. Theme Business case
      5. Requirements from relevant stakeholders 
      6. New external API's to be used
    2. Bottom-up requirements analysis (requirements coming from customers, current processes, and systems). Gather, discuss and study:
      1. Relevant existing screens, current system architecture, API's, manual processes/workflows
      2. Relevant data: analytics/revenues/costs / other data points (i.e. for a fraud reduction feature current fraud costs/types /patterns. For a new service: how often was it requested or how many times is a currently a  workaround solution used). 
    3. User Need analysis
      1. Contact Customer Support for input relevant to the theme (support has daily contact with customers. Not talking to them is unacceptable). 
      2. Study relevant User Interview (summaries) and User Test outcomes (from Discovery process) 
      3. Describe the overall Job to be done (JTBD) or Outcomes the User is trying to achieve.
      4. Describe the Persona's
    4. Competitor analysis
      1. Look at least 2 competitors, study their service, put screenshots of their relevant service in the project folder.
  2. Start working on the Design (Specifications and UI). 
    1. Start writing Epics to document the requirements in Jira. Only titles are mandatory. Follow the User Story title naming convention below. Example epics "Order eBook", "Download eBook". Each user role type will have a separate Epic (i.e. buyers, sellers, admins). 
    2. Map out the User Journey for the whole theme (per Actor), using Steps. Use the Extended User Story map for this Some UX designers like to create a Customer Journey Map in parallel which is also based on these steps. 
    3. Per step start writing relevant User stories. Read the paragraphs below about correct user story titles, how to split them up and what makes good user stories. 
    4. Initially, start with just the User Story title, but add them directly to Jira as issue type Design User Story. (If you want to separately track the status of the UI Design part of User Story in Jira you can create subtasks for that, however, you can also use Invision for that). 
    5. Prioritize the User stories together with the UI&UI Designers in Jira in the Design Backlog. Again the User Story map is a great tool to help set priorities. 
    6. Start working on Designs in the Design Backlog priority order. This includes adding user story description including Acceptance criteria (please review the linked page!) and UX&UI Designs. 
    7. In parallel work over overall requirements artifacts as soon as needed for a user story, and only the part that is needed.
      1. the Business Object model to show relationships between entities and Entity Definitions to name and precisely define all entities in the system (i.e. "Order", "NewsItem")
      2. State diagram in case of cross-role workflows or entities for which correct state (transitions) are crucial (i.e. Order, Project) 
      3. Workflow diagrams using UML Activity Diagram for complex human or automated workflows (an entity i.e. a task goes through several stages over several days) 
      4. UX might want to start on the Styleguide and set up a Design system (reusable components) and start on the Information Architecture
    8. If any issues come up during design that somehow prevents moving on what a certain part of the design (i.e. a decision has to be made by a stakeholder, a lawyer has to check something, some API is broken):
      1. Do your best possible assumption and continue the design using that.
      2. Document the issue on an Issue list in Trello. Per issue be very clear about the problem and impact, the proposed next step, the owner of the next step of the priority of this issue in relation to other issues. 
      3. Contact the relevant person about the issue. 
  3. Regularly gather feedback on the Design while it is in progress (again together with UX&UI Designer(s)). The User Story map provides a great tool for this meeting as it gives a process overview. 
    1. Architects about the technical feasibility. Ask the CTO or architect to start working on the technical architecture, tool, and framework selection, etc..
    2. Peers for peer reviews (i.e. other PM's, Head of Product). Recommended: weekly. 
    3. Stakeholders (i.e. CEO, Head of Customer Support)
    4. From end users using User Tests on a (partly) clickable Design in Invision. Recommended: bi-weekly. 
  4. Gather relevant Scrum team for Questions, Feedback, and Estimation in a Backlog grooming session.