ixigo Product Designer Interview: Questions, Experience & Prep (2026)

ixigo is one of India's leading travel tech platforms, serving millions of travelers who book trains, flights, and buses. The company builds for price-sensitive, mobile-first users, many from Tier-2 and Tier-3 cities, which makes the Product Designer role genuinely challenging. You are not designing clean interfaces for metro power users. You are designing for low-bandwidth connections, multilingual contexts, and users who may be booking a train for the very first time.

With 14 open Product Designer roles currently listed, ixigo is in an active hiring phase. Candidates typically report a process of 2-4 rounds: a recruiter or HR screening call, a portfolio walkthrough with the design team, a design exercise or take-home case study, and a final round with a senior design lead or product manager. The focus across rounds is on your thinking process, not just the final screens.

ixigo products operate at real scale for Indian users, so interviewers tend to probe how well you understand constraints like slow connectivity, regional language needs, and users with low digital literacy. Knowing the ixigo app well before your interview is not optional.

These are the questions candidates most commonly report from ixigo Product Designer interviews. Expect a mix of portfolio deep-dives, product thinking, and design process questions.

1. Walk me through a project in your portfolio where you improved an existing product, not designed from scratch.
2. How would you redesign the ixigo train ticket booking flow for a user in a Tier-3 city with a slow internet connection?
3. Describe a time you had a strong disagreement with a PM or engineer about a design decision. What happened?
4. How do you approach designing for users with low digital literacy? Give a real example.
5. Pick any screen in the ixigo app right now. What would you change and why?
6. How do you decide what to simplify versus what to keep in a complex booking flow?
7. Tell me about a design that failed after launch. What did you learn?
8. How do you measure whether a design is actually working once it is live?
9. ixigo serves many first-time flyers and train travelers. How does that change how you design onboarding?
10. How do you handle design when there is very little time for user research?
11. Describe your process for handing off designs to engineering. How do you make sure nothing gets lost?
12. How would you approach A/B testing a major change to the ixigo home screen?

Use the STAR format (Situation, Task, Action, Result) for all experience-based questions. Here are three examples tailored to what ixigo interviewers typically look for.

Q: Tell me about a time you improved a product for users with limited digital experience.

*Situation:* At my previous company, we noticed drop-offs on our payment page were highest among users from smaller cities.
*Task:* I was asked to investigate and redesign the flow to reduce abandonment.
*Action:* I ran usability sessions with a small group of Tier-2 city users, found they were confused by card-type selection labels, and redesigned the payment screen to use icons and plain-language labels instead of banking jargon. I also added a 'pay by UPI' shortcut as the first option since that flow was most familiar to these users.
*Result:* The team reported a clear drop in payment page abandonment in the first month post-launch. I can share the full case study if helpful.

Q: Describe a disagreement with a PM about a design decision.

*Situation:* My PM wanted to add four promotional banners to our app home screen to hit a revenue target.
*Task:* I felt this would hurt the user experience and long-term retention, so I had to make that case clearly.
*Action:* I pulled session recordings showing how users skipped banner-heavy sections, ran a quick user test showing confusion with the cluttered layout, and proposed an alternative: one contextual banner placed lower on the screen with a cleaner hero section.
*Result:* We ran both versions as an A/B test. My version had higher session depth, and the PM adopted the approach for future screens too.

Q: How do you handle design when there is no time for proper user research?

*Situation:* We had a feature that needed to ship in two weeks because of a partnership deadline.
*Task:* I needed to make design decisions without a full research cycle.
*Action:* I used three shortcuts: I reviewed existing support tickets to surface user pain points, ran quick corridor tests with colleagues who matched our user profile, and leaned on established design patterns for the category. I documented all assumptions so we could validate post-launch.
*Result:* The feature shipped on time. We used post-launch analytics and a short feedback survey to iterate within the following month.

These frameworks help you structure your answers clearly and show design maturity.

For 'how would you design X' questions: Start by questioning the problem, not jumping to solutions. State your assumptions about the user, their context, and their goal. Then narrow to one or two key user needs before showing any solution direction. ixigo interviewers commonly report that they want to see you slow down before sketching.

For portfolio walkthroughs: Use a simple arc: what was the problem, what did you not know at the start, what did you try, what did you learn, and what would you do differently. Avoid reciting feature lists. The interviewer cares about decisions and trade-offs, not deliverable counts.

For product critique questions (like 'what would you change in the ixigo app'): Be specific about the user you are designing for. 'I would improve usability' is weak. 'A first-time train traveler trying to book a tatkal ticket on a slow connection' is strong. Name one concrete problem and one concrete fix.

For metrics and measurement questions: Think in two layers. First, did the feature change user behavior (task completion, click-through, return visits)? Second, did it move a business metric (bookings, revenue per session, churn)? Showing you think in both layers signals product maturity.

For conflict or stakeholder questions: Do not just say 'I listened and compromised.' Show that you brought evidence (data, user quotes, test results) to the conversation and reached a decision based on that evidence, not just to keep the peace.

ixigo interviewers typically look for a few specific qualities that set strong candidates apart.

Deep empathy for Indian mass-market users. ixigo's core users are not metro power users. Candidates who design for smartphone-first, price-sensitive, sometimes low-literacy users, and who can talk about that with real examples, consistently stand out.

Clear thinking under constraints. The product team works fast and ships frequently. Interviewers want to see that you can make confident, well-reasoned decisions even without perfect information or unlimited time.

Portfolio that shows process, not just polish. ixigo design rounds typically focus on the 'why' behind your decisions. Interviewers regularly pause portfolio walkthroughs to ask 'why did you choose this pattern' or 'what did you try that did not work.' Have honest answers ready for both.

Product curiosity. Strong candidates come in having used the ixigo app recently, with specific observations. Vague praise ('I love the simplicity') reads as unprepared. Specific, thoughtful observations about real screens read as genuine product interest.

Collaboration and communication. ixigo works in cross-functional squads. Interviewers look for signs that you work well with PMs and engineers, not just in isolation.

A focused one-to-two week plan for the ixigo Product Designer interview.

Week 1: Know the product and the user

Spend real time using the ixigo app across at least three flows: train booking, flight search, and bus ticketing. Take notes on what works, what confuses you, and what you would change. Think about who the actual user is, not just yourself as a relatively tech-savvy person.

Read about ixigo's publicly available product philosophy and their focus on Bharat users. This context will make your answers sharper in every round.

Week 2: Sharpen your portfolio and practice

Select two or three portfolio projects that best show your process, not just final outcomes. For each, prepare a short walk-through that covers: the problem, the user, the constraints, what you tried that did not work, and the result.

Practice answering the questions from the list above out loud. Record yourself once. It feels uncomfortable but surfaces habits like filler words and vague answers.

Prepare one specific, constructive critique of an ixigo screen you would improve. Keep it focused, not a complaint list.

If you are juggling multiple applications at the same time, knok checks 150+ job sites nightly and applies to Product Designer roles matching your resume, so you can put your energy into interview prep rather than manual searching.

These are the patterns that most often cost candidates the ixigo Product Designer role.

Treating ixigo like a metro startup. ixigo's core market is Bharat, not Bandra. Candidates who default to 'clean minimal design for urban power users' miss the actual design challenge. Show you understand the real user base.

Showing only final deliverables in your portfolio. If your portfolio is all polished Figma screens with no visible thinking, interviewers have nothing to probe. Include at least one project where you share early sketches, a failed direction, or a decision you changed after testing.

Not using the app before the interview. Multiple candidates report being asked 'what would you change about ixigo?' in the first round. Walking in without a specific, thought-out answer is a clear missed opportunity and signals low preparation.

Giving vague answers to conflict questions. Saying 'I always try to find common ground' is not enough. Describe a real situation, name the trade-off, and explain how you resolved it with evidence.

Skipping the 'what I learned' part of every story. ixigo interviewers consistently value designers who reflect and grow. If your STAR answers always end with success and never with a lesson, they feel rehearsed and shallow.

Ignoring engineering constraints. If you propose a redesign that would take a very long time to build, interviewers notice. Show that you factor in technical feasibility and shipping speed in your design decisions.