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

Aris Infra is a construction-tech company building digital procurement tools for the Indian construction sector, connecting project managers, site engineers, and vendors on one platform. As of July 2026, they have 2 open Product Designer roles, signalling active design team growth.

The interview process typically includes a portfolio review call, a practical design challenge, and a conversation with a product manager or design lead. Candidates report that interviewers focus heavily on how you design for users who are not digital natives, how you handle multi-persona B2B products, and how you translate complex approval and procurement workflows into clean, usable interfaces.

The Product Designer role typically spans the full design cycle: discovery, research, wireframes, prototypes, and close collaboration with engineers and PMs. Market data from knok jobradar shows Product Designers in India earning 6-12 LPA at entry level (0-2 years), 14-24 LPA at mid level (3-5 years), 26-40 LPA at senior level (6-9 years), and 36-55+ LPA at lead or principal level.

These questions appear frequently in Aris Infra Product Designer interviews, based on what candidates have shared and the company's construction-tech context.

1. Walk us through a B2B product you designed. How did you handle the needs of different user types on the same platform?
2. Aris Infra's users include site engineers with limited smartphone experience. How would you design a simple material requisition flow for them?
3. Tell us about a time you simplified a complex, multi-step workflow. What was your process from problem framing to final solution?
4. How do you design for users in low-connectivity environments, such as construction sites or remote warehouses?
5. Describe how you approach user research when your target users are difficult to access, like field workers on an active project site.
6. Procurement managers need detailed data views while site engineers need quick, simple task completion. How would you design for both on a single product?
7. Have you designed an approval or escalation workflow? Walk us through your approach and the trade-offs you made.
8. How do you balance business requirements like mandatory fields and compliance steps with keeping the experience simple for end users?
9. Tell us about a design decision that was pushed back on by an engineer or PM. How did you resolve it?
10. How do you measure whether a design is actually working after it ships?
11. Have you designed for users in Tier 2 or Tier 3 cities, or for those who prefer regional language interfaces? What did you learn?
12. How do you work within an existing design system, and have you ever helped build or improve one?

Use the STAR format (Situation, Task, Action, Result) for all behavioural questions. Here are three example answers shaped around the Aris Infra context.

---

Q: How would you design for users with limited smartphone experience?

*Situation:* At a previous company, I was asked to design a daily field-reporting feature for construction supervisors. Most of them used entry-level Android phones and had never used a product management app before.

*Task:* My goal was a reporting flow they could complete quickly without any training materials or support calls.

*Action:* I visited several project sites to observe supervisors during shift handovers. I found they preferred taking photos over typing and often had unreliable network connectivity. I designed a photo-first flow with large tap targets, short regional-language labels, and offline sync. I tested paper prototypes with a small group of supervisors before writing a single line of spec.

*Result:* Daily report completion improved after launch, and the team reported a clear drop in field support escalations. One supervisor told us, 'This is the first form that doesn't feel like homework.'

---

Q: Tell us about a design decision that was challenged by engineering.

*Situation:* I was designing a procurement dashboard and proposed an inline editing feature so managers could update order quantities without leaving the list view.

*Task:* The engineer on the project explained that the existing architecture made inline editing costly to build and maintain reliably.

*Action:* Rather than insisting, I ran a quick usability session with several procurement managers to understand how often they actually edited orders versus just viewing them. The data showed that most edits happened right after an order was placed, not from the list view. I redesigned the edit trigger to appear on the order creation confirmation screen instead.

*Result:* Engineering built the feature in substantially less time than originally estimated, and the solution tested better with users because it caught errors at the right moment. The PM later cited it as an example of 'designing with constraints.'

---

Q: How do you measure the success of a design after it ships?

*Situation:* After shipping a redesigned vendor onboarding flow at a B2B SaaS company, my manager asked me to demonstrate that the redesign was worth the time invested.

*Task:* I needed to define success metrics before launch and track them systematically afterward.

*Action:* I worked with the data team to set up funnel tracking on each onboarding step. I also scheduled follow-up calls with several newly onboarded vendors to capture qualitative pain points the numbers alone would not surface.

*Result:* The funnel data showed a clear improvement at the step we redesigned. The vendor interviews uncovered two additional friction points we fixed in the following sprint. I documented the process as a repeatable template for future feature launches.

For design challenge questions: walk the interviewer through your process, not just your final screens. Cover who the user is, what problem you are solving, what constraints apply, what alternatives you considered, and what you would test next. Aris Infra interviewers typically want to see structured thinking rather than polished visuals alone.

For portfolio walkthroughs: choose projects where you can speak to impact and trade-offs. Avoid presentations that show only final designs. Candidates report that interviewers commonly ask, 'What would you do differently?' so prepare an honest answer in advance.

For 'why Aris Infra' questions: connect your interest to the construction-tech space directly. Talk about designing for users who are not office workers, or about the challenge of bringing digital tools to an industry that still runs on spreadsheets and phone calls.

For conflict and collaboration questions: structure your answer around three points: what the disagreement was, what data or user insight you brought to the table, and what the outcome was. Avoid framing yourself as always right. Interviewers value maturity and curiosity over defensiveness.

For 'measuring success' questions: name specific types of metrics such as task completion rate, error rate, time-on-task, and qualitative user feedback. Show that you think beyond aesthetics to actual user behaviour and business outcomes.

Domain empathy, not domain expertise. You do not need to know construction procurement before interviewing. Interviewers typically want to see that you can quickly understand an unfamiliar user's world, ask the right questions, and design for real constraints rather than your own assumptions.

Process over polish. Aris Infra serves a sector undergoing rapid digital transformation. Interviewers care more about how you think through a problem than how refined your Figma screens look on the first attempt.

Collaboration signals. Product Designers here work closely with engineers and PMs. Expect questions that probe how you handle feedback, scope constraints, and disagreement. Show that you treat engineering constraints as design inputs, not blockers.

Mobile and low-literacy sensitivity. Many Aris Infra users access the product on mid-range Android phones in noisy, busy field environments. Candidates who demonstrate experience with, or genuine sensitivity to, this context stand out in interviews.

End-to-end ownership. Interviewers look for candidates who follow a feature from initial research through to post-launch analysis. Show that your involvement does not stop at handoff, and that you care what actually happens after a design ships.

Two weeks before: research and portfolio prep

Spend time understanding what Aris Infra's platform does and who uses it. Read about construction procurement in India, material management workflows, and common pain points for contractors and project managers. Select two or three projects from your portfolio that show B2B design, complex workflow simplification, or designing for non-tech users.

One week before: practice and challenge prep

Practise a timed portfolio walkthrough out loud, ideally with a friend or peer as the audience. Candidates report that Aris Infra typically includes a design challenge focused on a real-world workflow problem. Practise structuring your response using: user context, problem framing, design options considered, trade-offs made, and what you would test next.

Two to three days before: story prep

Prepare STAR stories for these three scenarios: a time you designed for an unfamiliar or non-tech user, a time you resolved a design and engineering conflict, and a time you used research to change a product decision. Also review the salary ranges for this role so you are ready for a compensation conversation. Market data from knok jobradar shows 14-24 LPA for mid-level and 26-40 LPA for senior Product Designers.

Designing for yourself, not the user. The most common error in design challenges is proposing solutions suited to a young, urban, tech-savvy user when Aris Infra's actual users look very different. Always state your user assumptions out loud before you start designing.

Skipping problem framing. Jumping straight into solutions without defining the problem signals shallow thinking. Interviewers want to see you question the brief before you open any design tool.

Showing only final screens. A portfolio with no messy middle (research notes, sketches, failed directions) makes it hard for interviewers to assess your thinking. Include at least one example of a direction you explored and then abandoned.

Focusing on polish over impact. Discussing colour systems and micro-animations is fine, but if you cannot connect your design to a user outcome or business result, it reads as surface-level work.

Not asking clarifying questions. Candidates who accept a vague brief without probing it often miss the real user need. In a live challenge, asking a few good clarifying questions is a strong positive signal, not a sign of confusion.

Ignoring stated constraints. If the brief mentions mobile use, offline functionality, or low-end devices, designs that ignore those constraints suggest poor situational awareness. Always design within the context you are given.