Дизайн внутренних продуктов: сложные интерфейсы, техноцентричность и вызовы для дизайнеров

Main ideas & lessons (about designing internal products)

1) Why internal products are hard (especially for designers)

• Designers must absorb highly technical, domain-specific context (CI/CD, deployment systems, developer tooling, reliability infrastructure).
• There isn’t always a clear “consumer-like” mental model: internal tools serve developers/testers/data engineers, and the “user story” is often opaque to outsiders.
• Different designers learn complex context at different speeds, and this “context absorption skill” often isn’t taught explicitly.
• Internal products often lack open references/benchmarks, and planning is harder without measurable success metrics.

2) Choosing internal products vs building B2C

• B2C product patterns are often already “solved,” so you mostly iterate on known mechanics and chase conversion/UX improvements.
• Internal products are described as a “Wild West”:
  • fewer established patterns,
  • more room to invent or redesign mechanics,
  • potentially higher impact because internal reliability and tooling quality directly affect production stability and support load.
• Internal work can have direct company impact (e.g., fewer failures, faster deployments, better developer workflows), though it’s sometimes harder to measure.

3) Key capabilities for internal product designers

Designers need a mix of:

• Technical mindset
• Curiosity

They should be able to work across:

• business goals
• user needs (internal users)
• technical constraints

They also need enough implementation understanding to avoid producing “pretty but unusable” designs—for example, how to deploy/roll out on test environments and how release mechanics work.

4) Methods to develop products you don’t use

“Not using” the product yourself isn’t fatal, but you must compensate with immersion and validation.

Practices mentioned:

• AA training / bootcamp (junior-level learning) to absorb domain basics (e.g., a BI bootcamp for data-engineering services).
• Deep immersion with developers:
  • sit with engineers,
  • learn deployment/testing flows,
  • create small changes/requests to understand how the system behaves in practice.
• Even when external references exist, they may not match internal architecture—so adapt small pieces rather than copying entire systems.

5) Research and collaboration (“case-dev”)

For internal/technical tools, case-dev is practically mandatory:

• Research is hard to replace with generic templates because internal tools are “non-optional” for teams (you can’t simply switch away).
• Users often give blunt, detailed feedback because the tool is essential.

Designers should ask the right questions and not assume pain points are obvious.

Listening/verification is needed because:

• one person’s complaint may not represent real priority,
• designers must distinguish inconvenience from true business/user pain.

6) How internal teams prioritize feature work

Common feature request practices:

• Track how many requests exist (volume as an indicator).
• Collect requests on a board (e.g., Jira).
• Allow upvotes/voting to surface the most pressing items.

“Mission critical products” approach:

• When a major stakeholder team requests core functionality, teams may get more latitude due to high business impact.

7) Hiring and selecting designers for internal products

Hiring is less about “making it pretty” and more about:

• asking good why questions,
• digging into underlying workflow,
• handling technical/complex systems.

Assessment approaches:

• Whiteboard/trial tasks: focus on thinking and collaboration, not only reproducing memorized answers.
• Use either:
  • a product-like scenario, or
  • a collaboration format resembling real work (grooming → brainstorming → drafts → final).

Soft-skill/organizational fit matters:

• Some candidates have strong technical opinions and must collaborate constructively.
• Others are strong visually but may not dig deeply—fit depends on product complexity.
• Designers may be redirected into different “streams” based on observed strengths.

8) The economic/value argument for design involvement

Internal product design should justify ROI; otherwise it’s hard to claim “design is necessary.”

Because a designer’s cost and taxes may be substantial, value must show up as:

• faster onboarding,
• reduced errors/failures,
• faster time-to-market,
• operational savings (even if measurement is imperfect),
• reduced customer support load / reduced call duration (example discussed).

Important nuance:

• The best design decision might be not to change UI, or even to let developers handle parts when the issue isn’t critical.

9) Handling disagreement with developers (design vs engineering)

When developers challenge designs, it’s often due to:

• low trust, not necessarily bad UI taste.

Expected response pattern:

• provide evidence (user tests, k-tests, data),
• show other examples,
• but more importantly, build trust systematically.

“Tactics” for building “credit of trust”:

• Run demos for developers explaining:
  • research insights,
  • why a solution exists,
  • what problems were discovered,
  • what data supports the decision,
  • and share wins/metrics to reinforce credibility.

Demonstrating context reduces “strange questions” and shifts debate from “where to place a button” to shared understanding.

---

Methodologies / practical instructions

A) How to develop an internal product you personally don’t use

• Do domain immersion
  • learn basics via structured training (e.g., BI bootcamp for related internal tooling)
  • shadow developers/testers/data roles where possible
• Validate by learning through hands-on implementation
  • understand rollout/deployment and testing mechanics (at least enough to run it on a test environment)
  • ask a developer to guide you through changes/requests
• Use research and direct communication
  • conduct case-dev / deep interviews with tool users
  • gather feedback from people who must use the tool daily
• When references are available:
  • don’t copy whole competitor systems
  • extract only small reusable pieces that fit your architecture
• When references are missing:
  • work from the goal/problem and build mechanics from scratch
  • accept strategy planning is less metric-driven and needs stronger hypothesis management

B) Research approach for internal technical tools (“case-dev”)

• Treat the tool as essential/non-replaceable:
  • users will give candid feedback; use it
• Ask “why” and quantify pain:
  • distinguish inconvenience from priority
  • compare multiple users’ needs before advocating a feature
• Use internal prioritization signals:
  • count requests,
  • use boards/upvotes,
  • include mission-critical exceptions

C) How to handle “developers say it’s crap” while defending design

• First check the real driver:
  • assume low trust may be the underlying cause
• Respond with:
  • evidence (tests, data, prototypes validated with users)
  • a clear rationale tied to research findings
• Build trust systematically:
  • schedule regular demos for developers:
    • explain research results and root causes
    • present solutions in context
    • share positive outcomes and metrics when available
• Only then push forward with stronger UI/UX recommendations.

D) Hiring filters / evaluation criteria for internal product designers

• Evaluate beyond “visual polish”:
  • can they ask deep questions (why/what/for whom)?
  • can they understand complex workflow and technical constraints?
• Use assessment tasks that reflect reality:
  • whiteboard sessions requiring collaboration and reasoning (not memorization)
  • tasks close enough to real product work to observe thinking style
• Match candidate strengths to product types:
  • some excel in highly technical or deeply analytical domains
  • others may be better for less complex but process-heavy internal tools
• Evaluate soft skills:
  • can they collaborate with strong engineering personalities without being “toxic” or dismissive?

---

Speakers / sources featured (as named in subtitles)

• Ksyusha Belyaeva (Ksyusha) — manages developer tools for MTS Digital integration platform; also a chapter of those platforms.
• Nikita — Head of the internal development design department at T-Bank.
• Gleb — mentioned as working at Ozon/“Azon” (designer context implied).
• Valeria — mentioned as running a service related to Republic (GitLab replacement).
• Pavel Aksyonov — referenced as CPO of Aircraft (context: borrowing pieces of logistics solutions from leaders).
• “Yandex Cloud / VK Cloud” — referenced as competitor/reference examples for internal cloud-like products (not direct speakers).