intangles UI/UX Designer Interview: Questions, Experience & Prep (2026)

Intangles is a Pune-based connected vehicle intelligence company that builds telematics and IoT platforms for fleet operators, OEMs, and insurance providers. Their product involves dense data dashboards, real-time vehicle tracking, driver behaviour analytics, and mobile apps used by fleet managers on the go. A UI/UX Designer at Intangles works at the intersection of complex data and everyday usability, turning raw telematics signals into interfaces fleet operators can act on quickly.

The interview process typically runs two to three rounds. Candidates report an initial portfolio review or screening call, followed by a design assignment (often a dashboard or mobile flow), and one or more discussions with the product and design teams. Intangles currently has 26 open roles listed on knok jobradar, suggesting active hiring across product and tech functions. The role rewards designers who handle information-dense B2B products well and collaborate closely with engineering in a fast-moving startup environment.

1. Walk us through a data-heavy dashboard or fleet interface you have designed. What decisions did you make to reduce cognitive load for the user?
2. How do you design for users who are not tech-savvy, such as truck drivers or small fleet owners managing vehicles for the first time?
3. Intangles surfaces real-time vehicle alerts to fleet managers. How would you prioritize and present multiple simultaneous alerts without overwhelming the user?
4. Describe your process for going from a product requirement to a high-fidelity prototype. What tools do you use, and at what point do you involve engineers?
5. How do you handle a situation where engineering says your design is too complex to build in the current sprint?
6. Tell us about a time you used data or user research to change a design decision you had already committed to.
7. How do you approach designing a product that lives on both a desktop web dashboard and a mobile app, sharing the same underlying data?
8. What is your approach to building a design system or component library from scratch in a small team?
9. How do you test a design with real users when access to your target audience is limited or hard to arrange?
10. Walk us through how you would audit and improve an existing screen you find poorly designed. Take us through each step of your thinking.
11. How do you think about accessibility when designing fleet or IoT dashboards used by professionals in varied, sometimes low-attention environments?
12. What signals or metrics do you look for after a design ships to know whether the change actually improved the user experience?

Q: Walk us through a data-heavy interface you have designed.

*Situation:* At my previous company, fleet managers were working with a screen that packed a large number of data columns into a single table. They were regularly missing critical vehicle faults because the layout gave equal visual weight to every column.

*Task:* I was asked to redesign the main fleet overview screen so managers could spot issues faster, without losing access to the full data when they needed it.

*Action:* I ran a quick card-sorting session with three fleet managers to understand which metrics they checked first every morning. I redesigned the screen with a summary card row at the top showing only those key metrics, and moved the full data table below the fold. I used colour coding strictly for status (red for fault, amber for warning, green for healthy) and removed decorative chart types that added no real information.

*Result:* In usability testing with the same managers, time-to-first-action dropped noticeably, and the team reported far fewer missed alerts in the weeks after launch. The product manager flagged the redesign as one of the highest-impact changes of that quarter.

---

Q: How do you handle a situation where engineering says your design is too complex to build in the current sprint?

*Situation:* I had designed a multi-step onboarding flow for a new driver app feature. The engineering lead flagged that two of the five screens had custom animations that would push the release date.

*Task:* I needed to either simplify the design or make a case for the original approach, while keeping the release on schedule.

*Action:* I met with the engineer to understand exactly which parts were costly. The animations were the only blocker. I proposed replacing them with simple fade transitions using standard library components, and asked the engineer to review a stripped-down prototype before I reworked the full file. I updated the specs the same day.

*Result:* Engineering delivered the full flow on schedule. The simplified transitions tested well with users, and I documented the decision in our design system so future work would account for implementation cost earlier in the process.

---

Q: Tell us about a time you used research to change a design decision you had already committed to.

*Situation:* I had designed a bottom navigation bar for a mobile fleet app with five tabs, following a pattern common in consumer apps. I was confident in the approach and had already presented it to stakeholders.

*Task:* Before development started, we ran a brief usability test with six participants, all fleet supervisors.

*Action:* Three of the six participants struggled to find the 'Reports' tab, which they used most often, because it was positioned last in the nav bar. Going back to the research notes, I found these users had a clear mental model around two core tasks: checking live vehicle status and pulling weekly reports. I redesigned the nav to surface only those two items prominently and moved everything else into a 'More' menu.

*Result:* The revised design tested much better in a follow-up session. My takeaway was to test earlier, even on designs I feel confident about. I now build a quick usability check into every sprint before the design goes to engineering.

For design process questions, use a four-step structure: what you learned about the user, how that shaped your decisions, what trade-offs you made, and how you measured success. Interviewers at product-led companies like Intangles want to see that your process is grounded in user needs, not just aesthetics.

For prioritization and trade-off questions, be explicit about what you deprioritized and why. Saying 'I cut X because this user group never actually needed it' is more convincing than 'I simplified the interface.' Have a concrete example ready from your own work.

For cross-functional questions (design vs. engineering, design vs. product), show that you communicate in the other team's language. Engineers respond to constraints and timelines. Product managers respond to user outcomes and metrics. Frame your answer around collaboration, not conflict.

For portfolio walkthroughs, lead with the problem, not the visuals. State the user pain point in one sentence before showing any screen. Then walk the interviewer through your reasoning at each decision point, including what you tried and rejected along the way.

Domain fit with fleet and IoT products. Intangles builds for professional users, not casual consumers. They want to see that you have thought about high-density data, real-time updates, and users who are often on the move or working in noisy, low-attention environments.

Ownership and craft. Candidates who can talk about the full journey from research to shipped product, including what went wrong and what they learned, stand out. Intangles is a growth-stage company where designers typically own significant parts of the product, not just one screen at a time.

Practical collaboration skills. Because the team is lean, you will work closely with engineering and product. Interviewers look for candidates who have navigated real trade-offs, pushed back respectfully, and kept projects moving without waiting for a manager to resolve every conflict.

A portfolio that shows thinking, not just outcomes. Bring annotated case studies that explain your decisions at each stage. A polished final screen with no process context is less useful to Intangles interviewers than a rough wireframe that shows clear, user-grounded reasoning.

Before the interview, explore the Intangles product if you can access it, especially their fleet dashboard or any publicly available demo. Take notes on what you find confusing or well-designed. Having a specific, informed observation about their own product signals genuine interest and sets you apart from candidates who only looked at the job description.

Build one strong case study around a data-heavy or B2B product. If your portfolio skews toward consumer apps, prepare a short design exercise showing how you would approach a fleet operations screen. You do not need to build it fully, but sketching the approach and walking through your decisions out loud is valuable preparation.

Review core fundamentals: information hierarchy, using colour for status versus decoration, progressive disclosure for complex data, and designing responsive dashboards for both desktop and mobile. These topics come up consistently in fleet and IoT product interviews.

Prepare questions to ask the interviewer. Strong questions for Intangles include: How does the design team currently collect user feedback? What is the balance between new feature work and improving existing flows? How closely do designers work with engineering on a day-to-day basis?

knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so while you are deep in interview prep you are not missing other openings that could be a strong fit.

Showing only visual output without explaining the reasoning. Intangles interviewers want to understand how you think. If your portfolio walkthrough sounds like a product tour, slow down and add the 'why' behind each decision.

Treating fleet users as generic consumers. Truck drivers, logistics coordinators, and fleet owners have very specific mental models and workflows. Saying 'I designed it to be simple and intuitive' without grounding that in observed user behaviour will not land well with a team that builds for professionals.

Not having an answer on measuring success. Every design decision you describe should have some outcome tied to it, even a qualitative one from a usability test. If you cannot say how you knew the design worked, it reads as untested and theoretical.

Over-engineering your answers on process. Candidates sometimes describe elaborate research rituals that bear no relation to how startups actually operate. Be honest about constraints, and show that you can deliver good design under realistic timelines and with limited resources.

Arriving without questions. Not asking anything signals low curiosity. Prepare at least two specific questions about the product direction, the team structure, or the design process at Intangles.