Hi there and welcome,

In this page, you will find the public version of the template that OpenClassrooms’s Product Design team use for any design work. You can copy/paste all the content below in your own Confluence space, and customize it to make it yours!

Enjoy!

note

HOW TO USE THIS TEMPLATE?

(Remove this panel once you don’t need it anymore)

This page is a Toolbox (blue star) for Product Design workflow

→ Choose the sections you want to use, and remove the others ((blue star) some are )

→ For each section, you’ll find more info in the expandable section below it

(blue star) When you complete a step:

→ Summarize the key takeaways inside the colored panel and use the expandable section to put all the details

→ Then, click on the panel and change the panel in “done” (green)

→ Don’t forget to delete all the info you don’t need anymore in the expandable section

(blue star) Thanks to this page, in the blink of an eye, you will see all the sections already done (in green) and all the sections to do (in purple)

HOW TO USE THIS TEMPLATE?

(Remove this panel once you don’t need it anymore)

This page is a Toolbox (blue star) for Product Design workflow

→ Choose the sections you want to use, and remove the others ((blue star) some are MANDATORY )

→ For each section, you’ll find more info in the expandable section below it

(blue star) When you complete a step:

→ Summarize the key takeaways inside the colored panel and use the expandable section to put all the details

→ Then, click on the panel and change the panel in “done” (green)

→ Don’t forget to delete all the info you don’t need anymore in the expandable section

(blue star) Thanks to this page, in the blink of an eye, you will see all the sections already done (in green) and all the sections to do (in purple)

Current state of the project

Estimated total duration: to fill

Estimated retro-planning:
(Add an estimation date for finishing each step)

1 - EMPATHIZE

note

AUDIT OF EXISTING

AUDIT OF EXISTING

Audit of existing should be done if the goal of this sprint is to modify an existing page or feature. It can be an analysis of the page or an analysis of the statistics.

(blue star) Best practices

  • Record or screenshot current pages or features


(blue star) Useful links and tools

note

DATA COLLECTION

DATA COLLECTION

(blue star) Useful links and tools

note

STAKEHOLDER WORKSHOP

STAKEHOLDER WORKSHOP MANDATORY

The goals of a stakeholder workshop are to review with them the business objectives of the feature, to be sure that everybody is aligned and to keep the objectives in mind as long as you work on your feature.

note

INTERVIEWS

INTERVIEWS

(depending on the number of interviews, you should plan 1 day for preparation + restit and 1h per interview)

Interviews should be made when you need qualitative feedback and insights from users.

(blue star) Best practices

  • Define the goals of your interviews → which info are you looking for?
  • Create an interview guide that you will follow during each interview

(blue star) Useful links and tools

note

SURVEYS

SURVEYS

Surveys should be made when you need quantitative asynchronous feedback from users.

(blue star) Best practices

  • Define the goals of your surveys → what are you looking for?
  • Always ask open questions
  • If you offer several options, always use the option “Other” with the possibility for the users to write a free answer

(blue star) Useful links and tools

note

SHADOWING

SHADOWING

Shadowing should be done when you need to observe a user using an existing feature or page. It can be done IRL or using a tool like Hotjar.

(blue star) Useful links and tools

note

COMPETITOR ANALYSIS / BENCHMARK

COMPETITOR ANALYSIS / BENCHMARK MANDATORY

Competitor analysis and other websites benchmarks should be made to understand how others have already treated the same subjects and detect standards and patterns.

(blue star) Useful links and tools

  • You can add a competitor analysis as a child page of this page

  • Pageflows

  • Mobbin

note

WHITE PAPERS

WHITE PAPERS

In this step, insert all the articles, video, etc., that are useful for you on this subject

(blue star) Useful links and tools

2 - DEFINE

note

EXPERIENCE MAP

EXPERIENCE MAP

Experience map should be used to visually represent the current experience of the user, with their pain points and the opportunities to improve. It should be based on the results of User Research

(blue star) Useful links and tools:

note

PERSONA + USER PROBLEM

PERSONA + USER PROBLEM MANDATORY

Persona and user problem help framing the problem we are trying to solve and for who.

(blue star) To be defined

  • The persona
  • The user problem: How might we…?

(blue star) Useful links and tools:

note

USER SCENARIOS

USER SCENARIOS MANDATORY

A user scenario is the fictitious story of a user’s accomplishing an action or goal via a product. It focuses on a user’s motivations and documents the process by which the user might use a design.

Priority

User

Scenario

Notes

note

UX WRITING DEFINITION

UX WRITING DEFINITION

In this section, UX writers (or others) can define some key elements of the writing: terminology, tone spectrum… It has to be thought early enough in the process, especially for key, structuring terms.

(blue star) UX writing definition must include

  • Writing strategy
  • Terminology
  • Tone spectrum

Terminology table

EN 

Title + def

Don’t use

FR

Title + def

Don’t use



3 - IDEATE

note

CO-CREATION WORKSHOP

CO-CREATION WORKSHOP

Workshops can be organized to involve other team members or users in the ideation.

It can be:

  • Ideation workshop (crazy 8, round-robin…)

  • Co-conception workshops (card sorting, brainstorming…)

  • Stakeholders alignment workshops

(blue star) Useful links and tools

note

CONSIDERED SOLUTIONS

CONSIDERED SOLUTIONS

Here you can describe all the solutions that were considered during the “ideate” step and, if relevant, why they haven’t been chosen.

note

USER FLOWS

USER FLOWS MANDATORY

In this step, you can embed a user flow made on Lucidchart or link to a Figma file.

(blue star) Useful links and tools

note

DATA HIERARCHY / INFO ARCHITECTURE

DATA HIERARCHY / INFO ARCHITECTURE

​

Domain model and OOUX

(blue star)​ Useful links and tools

note

DESIGN REVIEW / FEEDBACK

DESIGN REVIEW / FEEDBACK MANDATORY

Every design should be reviewed at least once by your peers, to ensure enough communication and sharing between everybody.

(blue star) Useful methodologies

  • Design critique

  • Channel for design feedback on Slack

  • Peer review with a dedicated designer

4 - PROTOTYPE & USABILITY TESTS

note

WIREFRAMES

WIREFRAMES MANDATORY

Wireframes are made on Figma, preferably in black and white.
Insert the link to your Figma file in the colored panel.

(blue star) Quality Criteria

  • User can complete a task
  • Edge cases are managed
  • Error states are managed (+ error prevention)
  • Admin Scenarios are designed if relevant
  • Exception scenarios are managed
  • Responsive states are designed (desktop/mobile/iOS)
  • Main empty scenarios are designed
  • Alternative scenarios are designed
  • Time to perform a task - Fitt's Law (distance) / Miller's Law (memory)
  • Information Architecture
  • Navigation is consistent
  • Navigation - user can navigate back and forth on any page
  • Navigation - users know where they are on the website
  • Interaction - the interface gives feedback on actions
note

USER TESTS

USER TESTS MANDATORY

Every feature should be tested by users - whether quantitatively or qualitatively.

(blue star) Useful links and tools

  • Always prepare a test protocol, with goals, hypothesis and scenarios detailed

  • Learn more about usability testing with our course

  • Lookback (for qualitative tests)

  • Calendly (to organize remote and in-person user tests)

  • Maze (for quantitative tests)

5 - UX CHECKPOINTS

note

STAKEHOLDER CONSULTATION

STAKEHOLDER CONSULTATION MANDATORY

Stakeholders must be consulted before sending the feature to development.

(blue star) What to check during stakeholder consultation?

  • business is aligned with the suggested solution

  • nothing important from the business point of view has been forgotten in the solution

note

UX CHECKPOINT

UX CHECKPOINT

Every UX solution is shown to the squad: PM, Solution manager, developers and QA.
It’s an opportunity to check if everybody is aligned on the solution and see if there are any questions or technical issues.

In this step, you can write the summary of the changes decided in this checkpoint, if any.

6 - UI FINAL SOLUTION & SPECIFICATIONS

note

FIGMA FINAL PROTOTYPE

FIGMA FINAL PROTOTYPE MANDATORY

Final prototypes are made on Figma

(blue star) Useful links and tools

  • Design system documentation

  • Adobe creative cloud (for punctual needs of Photoshop, Illustrator or After Effect)

  • Lottie for animations

(blue star) Quality Criteria

  • Consistency with the Design System
  • Visual hierarchy leads users to the required action
  • Colors guide the users
  • "Affordance" - An element clearly indicate its function
  • Icons clearly reflect the essence of an element
  • Spacing and Proximity laws
  • Alignments and grid
  • Accessibility
  • Motion & Interaction
  • Consistency with the standards - Jacob’s law
  • Consistency with branding
  • Emotional design

(blue star) Checklist for the Figma final prototype

  • All screens in every responsive format
  • Main scenario
  • Empty states
  • Loading states + skeletons
  • Error states + cases
  • Edge cases
  • For new components: states are described or illustrated. Material design reference is available.
  • Copy is final and keys are defined
  • Transition / scroll / pagination behaviours are described if needed
note

DESIGN REVIEW / FEEDBACK

DESIGN REVIEW / FEEDBACK

Every design should be reviewed at least once by your peers, to ensure enough communication and sharing between everybody.

(blue star) Useful methodologies

  • Design critique

  • Channel for design feedback on Slack

  • Peer review with a dedicated designer

note

FINAL PRODUCT DESIGN CHECKPOINT

FINAL PRODUCT DESIGN CHECKPOINT MANDATORY

Every final solution is shown to the squad: PM, Solution manager, developers and QA.
It’s an opportunity to check if everybody is aligned on the solution and see if there are any questions or technical issues.
In this step, you can write the summary of the changes decided in this final checkpoint, if any.

(blue star) Checklist before final commitment

  • The whole squad has been invited
  • The file has been sent 1 day before on the squad channel
  • Figma Final prototype checklist is complete
note

OTHER CONSIDERED SOLUTIONS

OTHER CONSIDERED SOLUTIONS

Here you can describe all the solutions that were considered during the “ideate” step and, if relevant, why they haven’t been chosen.

Considered solutions

Pros

Cons

Why it hasn't been chosen

7 - WHAT’S NEXT?

note

FOLLOW UP & NEXT ITERATIONS

FOLLOW UP & NEXT ITERATIONS

Once the feature or page is online, it should be followed to check if further iterations are needed. Here you can gather everything useful for next iterations.

(blue star) Best practices

  • Define KPIs to compare before/after the feature