/
OpenClassrooms - Product Design Workflow Template

OpenClassrooms - Product Design Workflow Template

Owned by Audrey Hacq
Last updated: Jan 11, 2022 by Asma Suleiman (Deactivated)
7 min read

 

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!

 

HOW TO USE THIS TEMPLATE?

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

This page is a Toolbox for Product Design workflow

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

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

 

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

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 TO START

Estimated total duration: to fill

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

Kick-off date: tape /date to add a date
Part #1 (Empathize) done :
Part #2 (Define) done :
Part #3 (Ideate) done :
Part #4 (Prototype) done :
Part #5 (Test & checkpoints) done :
Part #6 (UI final solution & checkpoints) done :
Part #7 (Next steps) done :

1 - EMPATHIZE

AUDIT OF EXISTING

0.5 to 1 day

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.

Best practices

Record or screenshot current pages or features


Useful links and tools

DATA COLLECTION

TO DO WITH PM

Useful links and tools

STAKEHOLDER WORKSHOP mandatory

0.5 day TO DO WITH PM

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.

INTERVIEWS

1 DAY to 2 days (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.

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

Useful links and tools

SURVEYS

1 day TO DO WITH PM

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

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

Useful links and tools

SHADOWING

0.5 day to 1 day

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.

Useful links and tools

COMPETITOR ANALYSIS / BENCHMARK mandatory

0.5 day TO DO WITH PM

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

Useful links and tools

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

  • Pageflows

  • Mobbin

WHITE PAPERS

0.5 day

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

Useful links and tools

 

2 - DEFINE

EXPERIENCE MAP

0.5 day

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

Useful links and tools:

PERSONA + USER PROBLEM mandatory

0.5 day

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

To be defined

The persona
The user problem: How might we…?

 

Useful links and tools:

USER SCENARIOS mandatory

0.5 day

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

Priority

User

Scenario

Notes

must have

 

 

 

should have

 

 

 

nice to have

 

 

 

won't do

 

 

 

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.

UX writing definition must include

Writing strategy
Terminology
Tone spectrum

Terminology table

EN 

Title + def

Don’t use

FR

Title + def

Don’t use

EN 

Title + def

Don’t use

FR

Title + def

Don’t use

 



 

 

 



 

 

3 - IDEATE

CO-CREATION WORKSHOP

2 days

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

Useful links and tools

CONSIDERED SOLUTIONS

1 day

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

USER FLOWS mandatory

1 DAY

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

Useful links and tools

DATA HIERARCHY / INFO ARCHITECTURE

1 DAY​

Domain model and OOUX

​ Useful links and tools

DESIGN REVIEW / FEEDBACK mandatory

0.5 day

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

Useful methodologies

  • Design critique

  • Channel for design feedback on Slack

  • Peer review with a dedicated designer

4 - PROTOTYPE & USABILITY TESTS

WIREFRAMES mandatory

1 DAY

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

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

USER TESTS maNdatory

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

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

STAKEHOLDER CONSULTATION mandatory

0.5 day

Stakeholders must be consulted before sending the feature to development.

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

UX CHECKPOINT

0.5 day

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

FIGMA FINAL PROTOTYPE mandatory

Final prototypes are made on Figma

Useful links and tools

  • Design system documentation

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

  • Lottie for animations

 

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

 

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

DESIGN REVIEW / FEEDBACK

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

Useful methodologies

  • Design critique

  • Channel for design feedback on Slack

  • Peer review with a dedicated designer

FINAL PRODUCT DESIGN CHECKPOINT mandatory

0.5 DAY

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.

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

OTHER CONSIDERED SOLUTIONS

1 day

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

Considered solutions

Pros

Cons

Why it hasn't been chosen

 

 

 

 

 

 

 

 

7 - WHAT’S NEXT?

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.

Best practices

Define KPIs to compare before/after the feature