UI/UX Design Guide: From Figma to Your First Case Study

The first UI/UX exercise needs no Figma at all. Pick an app you open every day, such as a food delivery app or a digital wallet, and complete one small task in it: sign up, change your address, or find an old transaction. Count the steps, and mark every moment your thumb pauses because you are unsure what to tap next.

Then split those notes into two columns. Complaints about a winding sequence, a feature buried in an unexpected menu, or a confirmation that never shows up go in the UX column, since they concern order and logic. Complaints about tiny text, a main button coloured the same as every other button, or an icon whose meaning is unclear go in the UI column, since they concern how the screen looks. Don Norman popularised the term user experience in 1993 while working at Apple, and ever since, UX has meant the whole experience of using a product, with UI as the part you see and touch.

The exercise sounds simple, yet this is where a designer's way of looking at products starts to form. Learners who sort problems this way know which layer they are working on when they later build a user flow or pick a palette. Repeat the drill on three different apps during the first week and compare what you found.

User research sounds like a job for a large team, but the beginner version can be run by one person in a week. Choose a problem close to everyday life, say students struggling to schedule group work, and find three to five people who live with it. The number five reflects what many practitioners report: after the fifth person, new complaints tend to echo earlier ones.

Everything hinges on how questions are phrased. An open prompt such as "Tell me about the last time you set up a group meeting. What happened?" draws out a story you can take apart. A leading one such as "You'd love a reminder app, right?" only earns polite agreement. During the interview, write down the person's exact words and resist drawing conclusions while still listening. Those original quotes become very valuable in the case study later.

After five interviews, group the notes by similar complaints, then write a short persona: an invented name, habits, goals and the main obstacle. Finish with one sharp problem statement, for example "Students with part-time jobs struggle to find shared free time because their group's schedules are spread across several apps." A statement that clear steers every decision that comes after it. When a new feature idea pops up midway, the learner simply asks whether it answers that problem statement. If the answer is uncertain, the idea goes on a separate list for the next project.

A wireframe is a screen skeleton made of grey boxes, lines and placeholder text, with no brand colours, photos or final icons. The plainness is deliberate. While colour is absent, both the learner and anyone giving feedback can focus purely on placement: which information sits at the top, which button leads to the next step, and how much is visible before scrolling.

The most useful habit at this stage is producing three versions of each important screen. The first usually follows a pattern from apps people already know. The second tries to simplify, perhaps by merging two steps into one. The third tries a completely different arrangement, such as swapping a list for cards or replacing tabs with one long page. All three are then shown to one or two people with the question "What do you understand from this screen, and what would you tap first?"

Feedback on a wireframe is very cheap to act on, since it means moving a few boxes. The same feedback on a finished visual design can mean rebuilding components, changing colours and rearranging a dozen screens. That is why learners are encouraged to hold back on aesthetics until the flow makes sense to other people.

As the number of screens grows, redrawing the same button everywhere eats time and lets inconsistencies creep in. Components solve this. In Figma, buttons, input fields, cards and navigation bars are built once as main components and placed as instances across every screen. Editing the main component updates every instance automatically.

Each component then gets variants for its different states. A button might have default, pressed, disabled and loading variants. An input field might have empty, focused, filled and error variants. Building these variants trains learners to think about states that often get forgotten, especially error states and empty states. Components, colours, the type scale and the spacing rules together make up a design system, and for a learning project a small system of ten to fifteen components is enough.

Handoff is the stage where the design goes to developers. Figma's Dev Mode, available on paid plans, shows the size, spacing, colour and text of every element. The learner's part is naming components and colours consistently, marking interactions that a still image cannot show, and leaving notes for special cases. These habits let a design be built without endless back-and-forth questions.

Product recruiters read portfolios to see how a learner thinks, and thinking only shows through the story of the process. A strong case study answers four questions in order: what problem was found, what research was done to understand it, which design decisions were made and why, and what changed after the design was tested. One or two case studies that answer all four are enough to apply for a junior role.

Draft the story in Notion or Google Docs before pasting in a single image. An easy-to-follow structure opens with a one-sentence summary and the learner's role, then moves through problem and context, research and findings, the design process from wireframe to UI, test results, and reflection. In the research part, one original quote from an interviewee often persuades more than a long summary. In the decisions part, before-and-after image pairs show how the design evolved at a glance.

The closing reflection is the part beginners skip most often. Write down what went well, what you would change if you ran the project again, and the single most useful lesson. The case study can then go live on Behance, Dribbble, Notion or a personal site, and it is worth checking how it reads on a phone, since many recruiters open portfolios on small screens. Self-initiated practice projects are perfectly valid as long as the process genuinely took place.