East DelhiEnquire now Related but different roles
UX design studies how a person completes a task in a product. UI design shapes the screens and controls used during that task. UX asks whether the flow makes sense; UI asks whether the interface is clear and consistent.
The roles often overlap. A designer may research users, draw wireframes and later create the visual screens. Larger teams may divide these jobs.
Typical UX and UI work
UX work can include interviews, user flows, information structure, wireframes and usability tests. The designer finds where people become confused or blocked.
UI work includes colour, type, spacing, icons, controls, screen states and responsive behaviour. Figma is commonly used for layouts, components and prototypes.
- UX focuses on tasks and flows
- UI focuses on screens and controls
- Both use prototypes
- Both need feedback
- One person may study both
Choose through practice
Choose UX if you like research, structure and testing. Choose UI if you like visual systems, typography and detailed screen design. Many beginners study both before selecting a focus.
The UI UX course at TGC East Delhi is taught at its Nirman Vihar centre. A portfolio should show the problem, process, decisions and final interface, not only attractive screens.
Design begins before visual styling
A team first needs to know what the product should help a person do. Research may involve interviews, support records, surveys or observation. The designer turns these findings into flows and early wireframes. Testing an early draft can reveal a bad assumption before time is spent on polished screens.
Research does not mean asking users to design the product. It means learning about their goals, terms and difficulties. The designer combines that evidence with business needs and technical limits, then tests whether the proposed flow works.
A case study should explain decisions
A UI UX portfolio needs more than screen images. A case study can state the problem, target user, role, constraints, main flow, test method and changes made after feedback. It should be honest about whether the project was live, academic or self-directed.
Show enough process to make the reasoning clear, but do not fill the case study with unused templates. A short, well-explained project is stronger than a long document with no link between research and the final interface.
A practical exercise
Reading gives you the terms, but a small task shows whether you can use them. Set aside several short sessions and keep each step simple. Save the early version as well as the revised one so you can see what changed. Write a few lines about the reason for every major decision.
Do not judge the exercise only by how polished it looks. Check whether it meets the brief, works as expected and can be explained to another person. Ask for feedback from a trainer or peer, make one round of changes and note what you would do next with more time.
Begin with this step: interview one person about a routine task. Give the exercise a clear name, date and short brief. Keep notes as you move through the checklist, including any fault, question or change. End by doing this: write the result as a short case study. Store the source material with the result so a trainer can review how you worked, not only what you made. If a step does not work, record the reason and try a smaller version. This turns one exercise into evidence of planning, practice and revision.
- Interview one person about a routine task
- Draw the current steps in that task
- Create a low-detail wireframe
- Test the flow before adding colour
- Build reusable buttons and form fields
- Check text contrast and keyboard order
- Record what changed after feedback
- Write the result as a short case study