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
More details - 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
More details - data collection
TO DO WITH PM
β Useful links and tools
STAKEHOLDER WORKSHOP MANDATORY
More details - stakeholder workshop
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.
More details - 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
More details - 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
More details - 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
More details - competitor analysis
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
More details - 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
More details - 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
details persona + problème + scenario
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:
More details - user scenario
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 |
|---|
MUST HAVE | | | |
SHOULD HAVE | | | |
NICE TO HAVE | | | |
WON'T DO | | | |
More details - 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 |
|---|
|
| | |
|
| | |
3 - IDEATE
details 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
More details - 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.
More details - user flows
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
More info - data hierarchy / info architecture
1 DAYβ
Domain model and OOUX
ββ Useful links and tools
DESIGN REVIEW / FEEDBACK MANDATORY
More details - Design review
0.5 DAY
Every design should be reviewed at least once by your peers, to ensure enough communication and sharing between everybody.
β Useful methodologies
4 - PROTOTYPE & USABILITY TESTS
More details - wireframes
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
More details - user tests
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
More details - stakeholder consultation
0.5 DAY
Stakeholders must be consulted before sending the feature to development.
π What to check during stakeholder consultation?
More details - UX commitment
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
More details - Figma final prototype
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
More details - design review / feedback
Every design should be reviewed at least once by your peers, to ensure enough communication and sharing between everybody.
β Useful methodologies
FINAL PRODUCT DESIGN CHECKPOINT MANDATORY
More details - UI Commitment
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
More details - 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 |
|---|
| | | |
| | | |
7 - WHAT’S NEXT?
FOLLOW UP & NEXT ITERATIONS
More details - notes for 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