UI/UX design

What interviewers look for

• You design from users, not from taste: you can say who the users were, what problem they had and how you found out, by talking to them, watching them or reading data.
• A clear process from problem to tested solution, and proof that your design changed because of what you learned in research or testing.
• Real Figma skills: auto layout, components and variants, clickable prototypes, and organised files that a developer can open and use.
• Design for local conditions: small low-cost Android phones, slow or expensive data, people new to apps, and screens in Somali and English.
• Teamwork with developers and product managers: realistic designs, clear handoff, respect for technical limits, and calm acceptance that not everything gets built.

Questions they ask

1. 1“Walk us through one case study from your portfolio.”

   Why they ask: This is usually the first question. They check whether you can tell the story from problem to result, and what you personally did in a team.

   How to answer

   • Open with the problem and the users, then your role and who else was on the team.
   • Pick two key decisions and say what research or testing led to each one.
   • Close with the result, or what you learned if it never launched, and what you would change.

   This was the sign-up flow for a small delivery app in Hargeisa. I was the only designer, working with two developers. Many users stopped at the registration form, so I watched five people try it on their own phones. Most got stuck on the email field because they did not use email. We changed sign-up to a phone number with an SMS code and cut the form from eight fields to three. After launch, the developers' data showed more people finishing sign-up. Next time I would test before building the first version.

2. 2“How do you do user research when there is little time or budget?”

   Why they ask: Many companies here have no research budget. They want to know you will still find out what users need, with simple methods, instead of skipping users completely.

   How to answer

   • Talk to five or so real users; that already shows most of the big problems.
   • Use what already exists: customer service calls, WhatsApp complaints, app reviews and analytics.
   • Ask open questions about what people did, not leading questions about what they like, and share short findings with the team.

3. 3“What is the difference between UI and UX?”

   Why they ask: A basic check that you see UX as the whole experience and UI as the visual layer, and that you do not treat design as decoration only.

   How to answer

   • UX is how it works and feels: the flow, the steps, whether people can finish their task.
   • UI is what people see and touch: layout, type, colour, buttons and icons.
   • Give one quick example where good UI could not save a bad flow.

4. 4“How would you design for users with low-cost phones and slow internet?”

   Why they ask: This is the real situation for many users in Somalia and Somaliland. They check that you think about screen size, data cost, dropped connections and people new to apps.

   How to answer

   • Start on a small Android screen, not a laptop, and keep pages light.
   • Design loading, error and offline states with a clear retry, and save progress in forms.
   • Use large buttons, simple Somali words, and test on a real cheap phone over mobile data.

   I start on a small Android screen, because that is what most of our users have. I keep pages light: compressed images, system fonts where possible and no autoplay video. Every screen has a loading state and a clear error with a retry button, because connections drop. Forms save progress, so a user who loses signal does not start again. I use large buttons and simple Somali words, and before handoff I test on a real low-cost phone over mobile data, not on office Wi-Fi.

5. 5“How do you make a design accessible?”

   Why they ask: They check that you design for people with weak eyesight, colour blindness or shaky hands, and for anyone using a phone in bright sunlight.

   How to answer

   • Name the contrast rule: at least 4.5:1 for normal text (WCAG AA), and say you check it with a contrast tool.
   • Never use colour alone for meaning; add an icon or words to errors and statuses.
   • Large tap targets, visible labels on form fields, readable text sizes and alt text for images.

6. 6“How do you hand your designs over to developers?”

   Why they ask: Many designers make beautiful screens that cannot be built. The panel, often with a developer in it, checks that you work with the team and deliver everything they need.

   How to answer

   • Involve developers before the design is final so they can flag what is hard to build.
   • Clean Figma files: components, auto layout, named layers, frames marked ready for development.
   • Design every state (empty, loading, error, success), add short notes on behaviour, and review the built screens.

   I share designs with the developers before they are final, so they can tell me what is hard to build. In Figma I use components and auto layout, name my layers and mark which frames are ready for development. I design every state, not only the happy path: empty, loading, error and success. I add short notes for behaviour, like what happens after a failed payment. When they finish, I check the screens on a real phone and list any differences in one shared document.

7. 7“Tell us about a time testing showed your design was wrong.”

   Why they ask: They want humility and a habit of testing. A designer who has never been proved wrong has probably never tested with real users.

   How to answer

   • Say what you assumed and why it seemed right at the time.
   • Describe what the test showed, in plain words, without blaming the users.
   • Say what you changed and what you now do differently at the start of a project.

   On a bill-payment screen I hid the account number field behind an icon to make the page look clean. In testing, three of the five people could not find it and thought the app was broken. I had designed for how it looked, not for how people used it. I brought the field back as the first thing on the screen with a clear Somali label. Since then, I test my first rough prototype with a few people before I polish anything.

Example answers are in English, the language most panels use. Say it in your own words.

Topics to revise

• User research (interviews, observation)Learning what users do and need by talking to them and watching them use a product. Know the difference between asking “what did you do last time?” and a leading question like “would you like this feature?”
• Personas and user journeysA persona is a short description of a typical user based on research, not imagination. A journey map shows the steps, feelings and pain points as that person tries to reach a goal, like paying a bill.
• User flows and information architectureA user flow is the path of screens and decisions to finish one task. Information architecture is how content and menus are grouped and named so people find things. Expect to sketch a flow on a whiteboard.
• Wireframes, mockups and prototypesA wireframe is a low-detail layout in grey boxes to agree structure. A mockup adds the real visuals. A prototype is clickable so people can test the flow. They may ask when you use each.
• Figma (auto layout, components, variants)Auto layout makes frames resize with their content. Components are reusable elements; variants are their versions, such as a button in default, pressed and disabled states. Be ready to build one live.
• Design systemsA shared library of colours, type styles, spacing and components with rules for using them, so a whole product looks and behaves the same. They may ask how you would start one for a small team.
• Accessibility and WCAG contrastWCAG is the common accessibility standard. Level AA asks for contrast of at least 4.5:1 for normal text and 3:1 for large text. Also: do not rely on colour alone, label form fields, and make tap targets large.
• Mobile-first and responsive designDesigning for the smallest screen first, then adding for tablets and desktops. Responsive means the layout adapts to any screen width. Many users here have narrow Android screens and limited data.
• Usability testingGiving real people a task on a prototype, watching without helping, and noting where they get stuck. Around five users usually find the biggest problems. Know how you would write a task and record findings.
• Usability heuristicsWell-known rules of thumb for judging an interface: show system status, speak the user's language, allow undo, prevent errors, be consistent. Useful when they ask you to critique their own app.
• UX metrics (task success, drop-off, conversion)Task success is how many users finish a task; drop-off is where they leave a flow; conversion is how many reach the goal, such as a completed payment. Panels like designers who check whether a change helped.

Practical tasks you may get

1. 1A live design challenge, 45 minutes to two hours: for example, “design a way for customers to pay a water bill” or “book a clinic appointment”. Ask who the users are and what the constraints are first, say your assumptions out loud, sketch the flow before any screens, and include the error cases.
2. 2A take-home challenge over a few days. Show your process, not only final screens: problem, assumptions, flow, wireframes, one tested idea. Keep to the time they suggest; if the brief looks like a full product they would launch, ask politely about the scope.
3. 3A 20 to 30 minute portfolio presentation of one or two case studies, often with a developer and a product manager asking questions. Rehearse with a timer, prepare the Figma links offline or as a PDF in case the internet fails.
4. 4“What would you improve in our app or website?” Use their product on your phone before the interview, note two or three problems with the reason and a suggestion for each, and be respectful: the people who built it may be on the panel.

Portfolio questions

• Two or three full case studies beat twenty pretty screenshots: problem, users, your role, process, decisions and result.
• Show the messy middle: research notes, sketches, wireframes, test findings and what changed because of them.
• Be honest about your role and whether it launched, label concept projects, and never show a client's confidential screens without permission.
• Make the portfolio fast and readable on a phone, and check that every Figma prototype link opens without a login.

Mistakes to avoid

• Showing only final screens with no problem, no users and no reasons for the decisions.
• Designing on a large iPhone or laptop frame when most users have small Android phones and limited data.
• Designing only the happy path, with no empty, loading, error or offline states.
• Talking about “users” without having spoken to any, or inventing persona details and research results.
• Light grey text and tiny buttons because they “look clean”, even though they fail contrast and are hard to tap.
• Messy Figma files with unnamed layers and detached components that developers cannot work from.

Quick check

5 questions. Answer each one to see the explanation.