Starvard.
Starvard University · UX Design 101
You will design websites and apps around real users by researching their needs, testing your ideas, and fixing what confuses them. This course follows Nielsen Norman Group foundational articles and public guides from Usability.gov and Digital.gov, and it teaches research, structure, and testing rather than visual decoration alone.
Hello, my name is Finn, and I'm going to help you understand this course.
Here it is, explained like you are 10:
UX design is about making websites and apps easy and pleasant for real people to use. Designers watch and listen to users, sketch ideas, build simple test versions, and fix what confuses people before anything is final. This course teaches you to interview users, map their journeys, organize pages clearly, test on a small budget, and turn one finished project into a portfolio piece that shows how you think and work.
Digital.gov describes the purpose of user research plainly: to understand the needs and behaviors of your users so you can develop a product or service that supports them. Combined with user testing, it helps ensure the product meets the needs of its users. That loop, learn from people, make something, watch people use it, and improve it, is the whole rhythm of this course.
You will also meet Nielsen Norman Group and its ten usability heuristics, broad rules of thumb for interaction design that the group credits to Jakob Nielsen. We summarize those ideas in our own words throughout the course, and credit NN/g in the Sources. By the end you will have researched, structured, sketched, prototyped, and tested one small project, and packaged it as a portfolio piece.
The whole course in brief
What you will be able to do after this course
The eleven lessons
Lesson 1
User experience design is the craft of shaping how a product feels to use, from the first tap to the finished task. Digital.gov draws a useful line inside it: usability is how easily and effectively people can accomplish their goals using a product, usually measured through testing with success rates and satisfaction, and it sits under the larger UX umbrella, which covers designing the overall experience of a product.
That means UX work is mostly not decoration. Graphic design teaches visual craft: color, type, and layout as expression. This course teaches a different job: research to learn what people need, structure so they can find things, and testing so you know whether your ideas survive contact with a real person in a hurry. A beautiful screen that nobody can operate has failed at UX, however fine it looks in a portfolio screenshot.
Hold on to a few working principles from Nielsen Norman Group, summarized in our own words and credited to NN/g. Keep people informed about what is happening, speak their language rather than your internal jargon, stay consistent, prevent errors where you can, and write error messages in plain language that help people recover. You will meet these ideas again in almost every lesson, applied to real screens.
Notice that UX is a team sport with named parts: research, architecture, interaction, content, and testing often involve different people. Learning the whole loop yourself, even on a small project, makes you useful to every one of those specialists, because you can speak their language and respect their evidence.
Lesson 2
Research comes before design, because designing without it is guessing with better tools. Digital.gov divides user research into two kinds. Generative research helps you discover behaviors and problems in the current environment, and you use it most when you first start. Evaluative research comes after you have a potential solution in mind, and you use it to pilot that solution with real users, for example through usability testing.
Interviews are the beginner friendly generative method. Sit with one person at a time, ask about their real work and recent experiences, and listen far more than you talk. Ask what they did last time, what was hard, and what they tried when they got stuck. Digital.gov guidance on interviews and testing stresses open ended, non leading questions, because a question that hints at your preferred answer will politely hand that answer back to you.
Take notes you can use later. Write down exact phrases people use for their goals and problems, because those phrases become your labels, headings, and search terms. Note surprises separately from confirmations: a surprise is new information, while a confirmation only tells you that you asked someone who agrees with you. A handful of honest conversations, listened to carefully, will beat a large survey you never really read.
Resist the urge to interview only people who are easy to reach. Colleagues and friends are kind, available, and dangerously unlike your real users in what they know. Digital.gov flags exactly this sampling problem. Recruit from the people who actually do the task, even when scheduling them takes patience.
Lesson 3
A persona is a short, vivid summary of a kind of user, built from research rather than invented at a desk. Digital.gov describes personas as semi fictional characters you can use to portray an individual or group of users, to improve the design, development, and accessibility of a service. A good persona names the person, their goal, their context, and the frustrations your research actually found.
Personas earn their keep in arguments. When a team debates a feature, the persona turns a taste contest into a testable question: would this help the person we met, in the situation she described, on the device she owns? Keep personas few and grounded. If a detail did not come from research, leave it out or mark it as an assumption to check, because decorative detail makes a persona feel true without making it true.
A user journey maps the path that persona takes through your product, step by step: arriving, searching, deciding, acting, and finishing, with feelings and obstacles noted along the way. Drawing the journey exposes the seams where people hesitate, repeat themselves, or give up. Design work then has a target: smooth the worst step first, rather than polishing the step the team happens to enjoy working on.
Review your personas once after the first design round. Research summaries drift as a project teaches you new things, and updating a persona with what testing revealed keeps the whole team designing for the users you have now, not the users you imagined in week one. Date the update, so the change is visible.
Lesson 4
Information architecture is the organization of your content: what groups things belong in, what those groups are called, and how a person moves between them. People arrive with a question in their own words and scan for a label that smells like the answer. When your labels match their words and your groups match their expectations, finding things feels effortless, even on a large site.
Build the structure from evidence, not from your org chart. Your interview notes already contain the vocabulary users reach for. Group content the way users group the problem, name groups in plain words, and keep important tasks shallow, reachable in a few confident steps. Digital.gov work on content and usability makes the same practical point in its own way: test the content as a whole, because people experience the structure, not your individual pages.
A simple check protects you. Give a new person your group labels alone and ask where they would look for three common tasks. If they hesitate or choose wrong, the problem is your labels, not their intelligence. Rename, regroup, and test again. Structure fixed early is cheap. Structure fixed after a hundred pages are published is a renovation, with all the dust that implies.
A second structure check is the first click. Show a person your starting screen and a common task, and note the very first thing they choose. First clicks predict journeys surprisingly well in practice: a confident first step usually leads home, and a wrong one compounds. Your labels do most of that work.
Lesson 5
Sketching is thinking on paper at the cheapest possible price. Draw rough screens with a pen, boxes for content, lines for text, and labels in plain words. At this stage ugliness is a feature: nobody defends a sketch as finished art, so the conversation stays on what the screen is for, what comes first, and what the person using it needs to do next.
NN/g ideas, in our own words, keep sketches honest. Show the state of things clearly, so a person can tell what has happened and what will happen next. Favor recognition over memory: show options instead of asking people to remember them from an earlier screen. Cut every element that does not serve the main task, because each extra item competes with the ones that matter.
A wireframe is a sketch with commitment: the same rough boxes, now arranged carefully, sized honestly, and shared with the team or a tester. Keep wireframes plain on purpose, without brand colors or final images, so feedback lands on structure and wording instead of taste. Run through your persona journey on the wireframe, screen by screen, and mark every place where the next step is not obvious.
Invite one honest critic to mark up your wireframes before any tester sees them. Fresh eyes catch the assumed knowledge you have stopped noticing: the abbreviation only your team uses, the button whose destination is a mystery. Ten minutes of this saves tester time for problems only real use can reveal.
Lesson 6
A prototype is a test version of your design that a person can click or tap through, built only well enough to answer the question you are asking. If the question is whether people understand your structure, linked wireframes are enough. If the question is whether a form feels manageable, build that form properly and fake the rest. Fidelity follows the question, never the other way around.
Digital.gov separates the research moments cleanly: once you have a potential solution, evaluative research pilots it with real users to see how it works. A prototype is what makes that piloting possible before anything is built for real. Every screen you fake is a week of engineering you did not waste on an idea that a single afternoon of testing would have corrected.
Keep prototypes honest and disposable. Tell testers it is a model, not the finished product, so they criticize freely. Build the main path and the error paths people are likely to hit, and leave rare corners unbuilt but noted. When a prototype teaches you something painful, thank it: it did its job at paper prices instead of production prices.
Resist rebuilding a prototype that worked. When a test goes well, the temptation is to polish the model into the product. Keep it rough until the questions are answered, because polish invites attachment, and attachment makes teams defend a design against the very evidence the prototype was built to gather.
Lesson 7
Usability testing means watching real people try real tasks on your design while they think aloud, so you can hear where their expectations and your screens disagree. Digital.gov offers a full script for conducting a test, organized around introductions, warm up, set up, task completion, follow up, and wrap up, and it reminds moderators that there are no wrong answers from the participant: the design is what is being tested.
You do not need a laboratory. A quiet room or a video call, your prototype, a few tasks written as realistic scenarios, and one participant per session will teach you plenty. Digital.gov indicators for a useful test include a clearly stated purpose, participants who actually use or would use the service rather than friends and experts on your team, and one moderator with teammates observing quietly and taking notes.
Run your sessions on a budget by keeping them short and focused: a few participants, the handful of tasks that matter most, and notes clustered by pattern afterward. Fix the problems several people hit, in the order they blocked the task, then test again briefly to confirm the fixes did not create new problems. Small, regular testing beats one grand study you can only afford once.
A practical budget trick is to test with the tools already in the room: phones for recording with permission, a shared document for notes, and screens you already have. Money in UX testing mostly buys recruitment and time. Spend your small budget there, on the right participants, rather than on impressive rooms.
Lesson 8
Words are interface. Buttons, labels, headings, instructions, and error messages decide whether a person feels guided or abandoned, and NN/g guidance, summarized in our own words, starts with speaking the users language: words, phrases, and concepts familiar to them, rather than internal jargon, arranged in a natural and logical order. Your interview notes are the dictionary for this work.
Apply the same care to mistakes. Good error writing names the problem in plain language, with no codes, and suggests a constructive next step, which is the NN/g position in our summary. Keep instructions where the action happens, not in a help page three clicks away, and keep them short enough to be read in the moment they are needed. Help and documentation should be easy to search, focused on the users task, and concise, with concrete steps.
Edit interface text like you mean it. Read every label aloud and ask whether your persona would say it that way. Replace system words with human words, one idea per sentence, and the most important word first in buttons and links. When two screens say the same thing differently, pick one wording and use it everywhere, because consistency is a kindness users can feel.
Keep a small style list for your interface words: the verbs for your main actions, the names of your main objects, and the tone for errors. Three screens written by three people in three voices will confuse users more than any single awkward sentence. Consistency in words is consistency in experience.
Lesson 9
Forms are where good intentions go to be abandoned, usually for ordinary reasons: too many fields, unclear questions, and errors handled rudely. Start by asking only for what the task truly needs, in the order a person would naturally think of it. Group related fields, label every field in plain words, and show format expectations before the person types, not after they fail.
Prevention beats correction. NN/g guidance, in our own words, holds that the best designs prevent problems in the first place, by removing error prone conditions or asking for confirmation before an important commitment. Add the forgiveness people expect from other products: a clear way to go back, undo, or leave a process without losing everything, because easy exits build the confidence to start in the first place.
When errors do happen, keep the persons work intact, place the message beside the field it belongs to, and say exactly what to fix in plain language. Let people review before a final submission that matters. Then test the form with a real person and count completions honestly: a form people finish is a design success you can point to, not a matter of opinion.
Watch for the silent failure: a person completes your form, but with the wrong information, because a question meant something different to them than to you. Completion alone is not success. In testing, ask people to say what they think a tricky question is asking before they answer it.
Lesson 10
A design is successful when people succeed, so measure the people, not your feelings about the design. Digital.gov frames usability through measurable outcomes such as success rates and customer satisfaction. In your own tests, record for each task whether the person finished, how long it took, where they went wrong, and how the experience felt to them, in their own rating or words.
Pair those observations with the quiet evidence your product collects: searches that find nothing, pages where visitors leave, and steps where accounts are abandoned. Numbers locate the pain; watching people explains it. Digital.gov research guidance makes the complementary point about synthesis: look for patterns across participants, debrief promptly, and present findings in a prioritized way the team can act on, rather than as an unprioritized basket of issues.
Choose a few measures before you redesign, write them down, and compare after. Did more people complete the key task? Did the worst journey step get faster or calmer? Report honestly, including where nothing improved, because a measure you only quote when it flatters you is decoration. Over a few cycles, this habit turns design opinions into a track record the whole team can trust.
Write your measures where the team will see them weekly, beside the work itself. A measure hidden in a report is trivia. A measure on the wall is a promise: this task, this success rate, until it improves. Small numbers, honestly kept, change what a team chooses to fix next.
Lesson 11
A portfolio piece is the story of one project, told so a stranger can judge how you think. Choose the project from this course, the one you researched, structured, prototyped, and tested. Hiring readers do not need ten shallow projects. They need one honest case where a real problem met real users and your decisions changed because of what you learned.
Tell it in the order it happened. State the problem and what your research found, with a persona or journey to make the users real. Show the early sketches beside the later prototype, and explain the two or three decisions that mattered most and the evidence behind each. Then show the test: what people tried, where they stumbled, what you changed, and what the measures did afterward.
End with reflection, not triumph. Name what you would do differently, what you still do not know about your users, and what you would test next. That candor is professional, and it is rare enough to be memorable. You began this course asking what UX design is. You finish it with proof, in a form you can show, that you can learn from users and design in response.
Ask a friend outside the project to read your portfolio piece cold and tell you where they got lost. That reading is itself a usability test, of your case study. If they cannot retell your problem, your evidence, and your fix in one minute, the piece needs the same medicine you gave your design.
Sources
This course is built from Nielsen Norman Group foundational articles and public guides from Usability.gov and Digital.gov. NN/g supplies the ten usability heuristics, summarized here in our own words and credited to NN/g, and the government guides supply the research, persona, and usability testing methods. All teaching prose here is original.
Graduation
You learned what UX design is, how to research and interview users, and how to summarize them as personas and journeys. You organized content, sketched and wireframed, built prototypes, tested on a budget, wrote clearer interface content and kinder forms, measured success, and packaged one project as a portfolio piece. You now own the full loop: learn from people, design, test, and improve.
Keep learning
This course is part of Starvard University, striving for greatness.
A note on accuracy: Much of what you read at Starvard was created with help from AI agents, working alongside people. We check what we can, but we cannot guarantee that everything here is true, current, or complete. If something really matters, your health, your money, a grade, a job, please verify it with a trusted source before you rely on it.