Essentials
8 guided hoursModules 1-2. An introduction with practical exercises and a small reviewed artifact.
DESIGN · BEGINNER FRIENDLY
Design experiences people can actually use.
Move from a user problem to a tested interface. Learn research, user flows, wireframes, visual design and prototyping through one focused design project.
COURSE OVERVIEW
The outline follows a design project from user research and flows to wireframes, visual design, a clickable prototype and usability testing. You will work towards a course discovery and enquiry experience.
OPTIONAL AI PRACTICE
Selected modules include an optional prompt-and-review exercise. Verify the result using the underlying skills taught in this course.
Explore the Prompting FoundationA STARTING POINT THAT FITS
Modules 1-2. An introduction with practical exercises and a small reviewed artifact.
Modules 1-6, including Essentials. Complete the core labs and an assessed practical project.
Two extension modules and a four-hour project clinic after practitioner readiness.
These are curriculum planning options. We confirm the timetable, delivery format, fees and required accounts before enrolment. Practitioner includes Essentials; the two durations are not added together.
Download the Curriculum PDFWHAT YOU’LL LEARN
Aspiring designers, students, founders and developers who want to create clearer digital experiences.
Basic computer skills and curiosity about how people use websites or apps. No design background is required.
THE COURSE OUTLINE
Each module connects a concept to a practical task. Open a module to see its topics and exercise.
User experience includes the learner's whole task, including uncertainty before a course choice and support after an enquiry. The interface is the visible and interactive part of that experience. Begin with the job people need to complete, not a favourite screen layout. A beautiful interface can still leave essential questions unanswered. A research question guides what you need to learn; an interview question helps a participant describe relevant experience. Ask about a recent course decision rather than asking whether they like your proposed feature. Obtain permission for participation and notes, avoid unnecessary personal information, and accept that convenient classmates may not represent future customers. Separate an observed statement from your interpretation and a product assumption. If a participant says they could not find a timetable, that is evidence about one experience. It does not prove that everyone wants a calendar integration. Use a traceable note table and make uncertain conclusions visible in the problem statement.
Write a research plan for a course discovery experience.
Information architecture determines how content is grouped, named and found. Organise Riverstone around learner questions such as level, duration and schedule rather than internal department names. Small classroom sorting activities can suggest labels to test, but they do not prove the perfect structure. Keep the structure simple enough to navigate and explain. A task flow describes steps and decisions required to achieve a goal. Include entry, course comparison, choice, enquiry and confirmation. Draw alternative paths such as changing a course or abandoning the form. A flow is not a sitemap: it explains progression through a task, including conditions and recovery when something goes wrong. Each decision should expose enough information to make a reasonable choice. A course card may show level and duration, while the detail screen explains prerequisites and schedule. Avoid requiring an enquiry merely to discover basic facts. Mark missing business information explicitly; inventing prices or guaranteed outcomes makes a layout appear complete at the cost of trust.
Create the flow from finding a course to making an enquiry.
Wireframes prioritise content and interactions before colour and decorative polish. Put the learner's primary decision in a clear position and group related facts nearby. Use realistic labels and enough content to expose problems. Grey boxes with meaningless placeholder text may look organised while hiding the actual information needed to compare courses. Progressive disclosure reveals detail when needed while keeping the main task understandable. A concise card can lead to prerequisites and module details. Essential constraints such as a mandatory skill or schedule should not be hidden behind decorative interactions. Choose what is visible using task needs, then test whether learners can find the rest. Design empty, loading, error and success states as part of the flow. An empty catalogue needs guidance; a loading state needs feedback; an error needs a corrective action. Retain valid input whenever possible. The wireframe should identify each state even when the prototype uses separate screens to simulate them.
Build low-fidelity wireframes for the full enquiry flow.
Suggest two user flows for this research brief. Trace each decision to the provided findings and list assumptions for testing.
Compare suggestions with real research notes and test the flow with a person before choosing it.
A visual system records type hierarchy, colour roles, spacing and component states. Start small enough to apply consistently: one body style, two headings, a spacing scale and reusable form controls. Record why each role exists. A collection of attractive swatches is insufficient when screens use different values without a clear relationship. WCAG AA ordinary text generally needs at least 4.5:1 contrast against its background; qualifying large text needs 3:1. Record measured pairs rather than assuming that dark-looking colours pass. Errors also need text or another meaningful cue, because colour alone is insufficient. These checks address selected criteria, not complete accessibility conformance. Design for narrow layouts and text enlargement, with persistent field labels, visible focus and logical reading order. A 44 pixel button height is a useful project design target, not a universal AA requirement. WCAG 2.2 target-size minimum uses 24 by 24 CSS pixels with specified exceptions; implementation checks must consider the actual criterion.
Design a small UI kit and apply it to your screens.
Choose a task that reflects the design question. For Riverstone, ask a learner to find a suitable beginner course and make an enquiry. Define observable completion before the session. A prototype should support the selected path and one meaningful recovery route; unrelated interactive decoration is unnecessary for learning whether the task is understandable. Give a neutral task, let the participant attempt it and note actions before explaining the interface. If you intervene, record the help and distinguish assisted completion from unassisted completion. Ask follow-ups about what they expected after the attempt. Participant comments and observed behaviour may differ, and both deserve a careful record. Describe each issue with its location, observation, task impact and proposed revision. A blocked enquiry deserves higher priority than a minor visual inconsistency. Small samples identify issues for design iteration; percentages from two classmates are not reliable population estimates. Retest a specific change and document what remains unknown after the revision.
Test the prototype with available volunteers and record findings.
A design rationale connects a need, evidence, alternatives and a chosen approach. Explain why course facts appear before the enquiry rather than saying the layout feels modern. Include constraints and trade-offs. A decision can be reasonable with limited evidence if its assumptions are visible and there is a plan to test them. Document required fields, errors, state transitions, responsive arrangements and content sources. Include assets and reusable components, but do not assume a developer can infer behaviour from colour and screenshots. If a rule such as reply time is unknown, mark it for the business owner rather than making the design dictate an unsupported operational promise. Present this as a fictional learning project, identify your own contribution and describe the limitations of recruitment and prototype scope. Show one before-and-after revision grounded in evidence. Avoid fabricated conversion numbers or testimonials. The strength of the case study is clear reasoning and observable improvement, not pretending that coursework was a live client engagement.
Present your case study, including what changed after testing.
AFTER THE CORE COURSE
Build an evidence and inclusion plan
Review the service before launch
Complete both four-hour extension modules and a four-hour project clinic. Entry uses the core project and readiness evidence.
BRING THE SKILLS TOGETHER
Design a responsive experience that helps a learner compare courses and send a clear enquiry. Show your research, decisions and improvements after testing.
A learning project using sample or permitted material. The final scope is agreed for your learning plan.
Course outline published by Hawa Enterprises. Updated . Ask about the learning plan.
GOOD TO KNOW
Figma is a practical design tool in the outline. The main focus is understanding users, making clear design decisions and testing the experience.
The capstone is structured as a case study you can develop for a portfolio. Present it honestly as a learning project and include your own contributions and research limitations.
These details are confirmed by email before you commit. The curriculum gives guided-hour options for Essentials, Practitioner and Advanced. Actual schedules, fees and delivery arrangements are confirmed before enrolment. Ask about the course you want and your preferred timeline.
Choose a course and complete the enrollment wizard with your name, email and WhatsApp number. Review your details before sending the enquiry. Hawa Enterprises will discuss your starting level, goals and course arrangements before enrolment is confirmed.
YOUR NEXT SKILL STARTS HERE
Tell us your goal, starting level and preferred timeline.