01 / THE CHALLENGE
Choosing a course involves more than its title.
The project’s heuristic review identifies weak hierarchy, missing filters, repetitive course cards, and actions that are easy to miss. The redesign focuses on helping a learner compare programs before committing to an enquiry or enrolment.
Repeated calls to action can help someone find a next step, but urgency and promotional claims should not drown out course information. The catalogue still has to support a careful comparison.
02 / MY ROLE & APPROACH
From content structure to responsive UI.
I worked from the heuristic review through desktop and mobile wireframes, visual styles, and finished layouts. Course comparison is the thread running through the work: what information to show together, and what the learner should do next.
Project timeline · design phases
- 01
Frame the task
Review hierarchy, filtering, and course-card clarity.
- 02
Organize the experience
Build desktop and mobile page wireframes.
- 03
Resolve the interface
Apply typography, color, buttons, and course patterns.
- 04
Prepare for execution
Resolve responsive layouts and the supporting sections.
03 / INFORMATION ARCHITECTURE
A page built around course evaluation.
The main areas of the product, and the information each one needs to keep together.
Find a program
- Category introduction
- Course filters
- Course catalogue
Evaluate
- Provider & qualification
- Duration & start date
- Mentors & FAQs
Take the next step
- View course
- Enrolment action
- Enquiry form
04 / USER FLOW
From discovery to a course enquiry.
A useful flow needs to account for what happens when someone cannot take the next step immediately.
- 01Explore courses
- 02Compare programs
- 03Check credibility
- 04Choose the next step
Not ready to enrol?
Use course details, mentors, FAQs, or the enquiry route to resolve questions.
05 / DESIGN DECISIONS
Helping learners compare the details.
Turn the review into a page structure
The documented review sets out the problems to address. Wireframes then organize the hero, course catalogue, supporting information, mentors, and FAQs into a clearer sequence.
Keep comparison details together
Course cards use a repeated structure for the provider, qualification, start date, and duration. “View Course” and “Enroll Now” give evaluation and commitment separate actions.
Resolve the mobile layout separately
The file includes dedicated desktop and mobile wireframes and UI designs. Stacked content and a narrower reading order keep the key course details available on smaller screens.
06 / THE WORK
From wireframe to interface.
Explore the screens below. Scroll through a longer page or open it for a closer look.
The original wireframe establishes the page sequence before color and imagery.
Open full design ↗
Course comparison, mentor information, and FAQs share a consistent visual hierarchy.
Open full design ↗
A separate narrow-screen structure gives the catalogue and supporting content their own reading order.
Open full design ↗
The same information reorganized for a small screen. Open the export to inspect the full page.
Open full design ↗
The source palette defines primary, secondary, and neutral colors.
Open full design ↗
The original typography sheet defines headings and supporting text.
Open full design ↗
Filled and outlined actions in the source UI styles.
Open full design ↗07 / DESIGN INTO DEVELOPMENT
Reusing the system across screen sizes.
Course cards should use a shared component so dates, qualifications, and actions keep the same order. At smaller widths, the catalogue and supporting sections need to reflow without hiding comparison details. Filter state and form feedback need explicit interaction rules.
08 / REFLECTION
A clearer structure for a considered choice.
The work includes the review, wireframes, visual direction, and responsive layouts. The design rationale describes intended benefits; it does not establish measured conversion gains. Comparison tasks and filter use would be useful subjects for a subsequent usability study.
Next, I would test course-comparison tasks, filter comprehension, and the difference between enquiry and enrolment actions. Accessibility claims in the design rationale need validation in the implemented interface.