Business case · UX/UI · SaaS
Docebo learning dashboard
The brief came with a persona already written: Julia, 30, sales rep, who knows her knowledge gaps and cannot easily show what she has learned. I designed an e-learning dashboard around her real problem, evidence of progress, rather than around course inventory.
- Type
- Self-directed business case, a brief taken on during a design selection process and run with my own method
- Scope
- Wireframes and interface for dashboard and courses
- Persona
- Supplied in the brief, not researched
- Tools
- Sketch
The brief
Docebo is a SaaS learning management system: companies use it to train employees, partners and customers. The brief asked for an engaging e-learning dashboard where a user can check the learning activity they have done on their company’s training platform.
Unusually, the brief supplied the persona. That is worth flagging rather than hiding: the empathise phase here was handed to me, and a persona I did not research is a persona I cannot fully defend.
The process, and what was real
Empathise
Partly delivered- Persona supplied with the brief
- Interviews with corporate learners (proposed)
- Platform analytics on course completion (proposed)
Define
Delivered- Needs and frustrations turned into design targets
Ideate
Delivered- Dashboard structure and content hierarchy
- Split between “where am I” and “what next”
Prototype
Delivered- Wireframes for dashboard and courses
- Interface for both screens
Test
Method proposed- Usability test with employees on a real platform (proposed)
- Completion-rate comparison (proposed)
Julia, as the brief describes her
Delivered supplied material, restated
What works for her
- Hard worker, and actively pursues learning opportunities
- Wants to demonstrate improvement
- Wants guidance on career development
- Wants an overview of how she is performing
What is in her way
- She knows where her knowledge gaps are
- She needs guidance to close them
- Achievements are hard to demonstrate to others
- Her own progress is hard to see
The insight I designed to
Every frustration on Julia’s list is about evidence, not about content. She does not need more courses. She needs to see her progress and be able to show it to somebody who decides on promotions. That turns a course catalogue into a proof-of-achievement tool.
Restated as a design target: give Julia an at-a-glance answer to “how am I doing?”, a credible next step, and something shareable at the end of it.
Wireframes
Delivered
Two screens carry the whole job: a dashboard that answers “where am I?” and a courses view that answers “what have I actually earned?”
Interface
Delivered
What each screen is doing
Dashboard
- An engaging call to action that pushes discovery of new courses
- A clear view of what is new and what is suggested for her
- Progress and achievements given prominence over catalogue
Courses
- Easy access to achieved certificates
- The ability to share and demonstrate new skills
- Engaging elements that reward working towards the next achievement
- A route to contact course instructors for guidance
Looking back
Method proposed written now, looking back: what I would keep and what I would do differently with the experience I have today
Reading “evidence, not content” out of the persona is the move that makes this case study worth showing. It is the difference between decorating a brief and interpreting one.
What I’d do differently: I accepted the supplied persona without pressure-testing it, and Julia is suspiciously tidy. A persona with no contradictions is usually a marketing artefact rather than a research one. Today I would ask what she was built from, and I would design the sharing mechanism properly: “demonstrate achievements” implies a manager on the other end, and that person never appears in my design. There is a second screen missing here.