Evgenii ShmoishSenior UX Designer

I design the software that experts live in all day.

10 years in UX design, 8 in enterprise software. I turn research into usable interfaces, component libraries and working prototypes.

Helsinki, Finland · Native German and Russian · Professional English

EmailLinkedInFigma

FA Solutions2022–present

4 product teams.
A shared UX practice.

As FA’s first UX designer, I made client research and a shared design system part of everyday development.

  • Research. I introduced interviews, usability tests and feedback sessions with clients across 5 countries.
  • Design systems. I led the MUI and AG Grid transition to improve consistency and reduce UI maintenance.
  • Prototypes. Clients tested real tasks in my React prototypes before production development.

FA’s platform covers portfolio and fund management, trading, compliance, reporting, and a client portal.

80+ client organisations · 15 feature areas

FA Solutions ↗
KALO · Kalorimeta2018–2022

3 designers.
Connected across applications.

I introduced UX processes across enterprise, Android and consumer apps, connecting research with design and implementation.

  • Research. I investigated needs, developed concepts and tested usability across applications.
  • Design systems. I established a shared design system and component library for B2B applications.
  • Collaboration. I coordinated 3 designers and a frontend developer group to keep implementation consistent.

Metering and billing for housing. Public digital services include the customer portal, resident portal and KALO Home consumption app.

50+ locations across Germany

KALO ↗

I make complex problems
clear enough to solve together.

I make ideas tangible early, so teams and clients have something concrete to question and test.

  1. 01UnderstandWhat is happening?
  2. 02Make it clearDo we see the same thing?
  3. 03ExploreWhat could work here?
  4. 04DecideWhat do we need to test?
  5. 05LearnDid it help people?

What we learn changes what we do next.

  1. 01

    Understand the problem behind the request.

    I analyse usage data alongside client conversations and business knowledge. I turn the findings into a clear problem, constraints and questions to investigate.

    Sometimes the useful answer is a reason not to build.

  2. 02

    Make it clear enough to think together.

    I turn findings into sketches, diagrams and working prototypes. Teams and clients can explore the idea, question assumptions and correct my understanding.

    The picture is useful when people can think with it.

  3. 03

    Find options that fit the real product.

    I explore solutions within the existing product and design system. With developers, I compare effort, constraints and trade-offs. With clients, I look for needs beyond the original request. A rough sketch or a working prototype makes those conversations concrete.

    One client’s request can reveal a need shared by many.

    An example of how I explore ideas How I work with agents
  4. 04

    Find the evidence a decision needs.

    I choose the test to fit the question: interviews, usability tests, A/B tests or analysis of existing data. I turn findings into recommendations the team can act on.

    Before building, we agree what success means for users and the business.

  5. 05

    Check what changes for people.

    After release, I combine usage data with user feedback to understand what changed. I use the findings to prioritise improvements and decide what to test next.

    I use what we learn to propose the next improvement.

I build agent tools
for thinking together.

I organise every agent project around three parts: trust, engineering and the useful tool that comes out of it.

  1. TrustShared understanding
  2. EngineeringReliable foundations
  3. ProductA useful tool

What we learn improves the context, code and tools.

Shared documentation and domain knowledge give agents context. Strict TypeScript, reusable components and automated checks guide how they build.

The outcome can be a prototype, a research wiki or a testing tool. The problem determines the form.

Teams already prototype with my agents.

  1. RequirementsTickets & questions
  2. Working prototypeBuilt in the meeting
  3. Team discussionTry, question, refine

My agents work with product documentation, existing interfaces and UX guidance. Teams give them tickets or guide them directly to explore designs and clarify requirements.

Shared components and strict TypeScript make the prototypes easier to align with frontend development.

Agents support a designer, who presents a working interface to a group of people.

I own the decisions
and the result.

I frame the problem, connect the findings and decide what to build. I review the output and present it to teams and clients, so we can question it together.

The question decides which tool I use.

I choose the form that helps people respond: a sketch to clarify an idea, or a working prototype to try a task.

  1. The screen as a wobbly pencil wireframe on paper: a list, a detail pane, a crossed image box and a button.
    SketchesPaper and whiteboards help me explain a thought while it is still easy to change.
  2. The same screen in marker on a whiteboard, with two sticky notes on it. One note asks a question.
    WorkshopsI bring the people who know the problem together to question and clarify it.
  3. The same screen as a clean high‑fidelity Figma frame with a frame name above it and pale fills.
    FigmaDetailed prototypes let people respond to the layout, content and behavior of a proposed interface.
  4. The same screen built in React in a browser: rows of real data, a chart in the detail pane, and a pointer on the one highlighted button.
    ReactWorking prototypes let people try realistic tasks with realistic data, including interactions a static screen cannot show.
  5. The same screen being built by an agent: the list stands, the detail pane is a petrol dashed edge still open, and a prompt line with a cursor sits below.
    AgentsI can build interactive drafts during a discussion, test ideas sooner and iterate faster.

I build tools for problems
I meet in my own work.

My 5 published Figma plugins grew from recurring design tasks: importing websites, managing typography, building data grids and working with images.

Web Import Master

Bring a website into Figma as an editable document.

Web Import Master demo video

A Chrome extension captures the page in your own browser. The plugin rebuilds it in Figma.

Both run locally, with no sign-up or upload. I built them to work with pages already open in the browser, including those behind a login.

PluginChrome extensionDocs

Four more tools, each built around one recurring task.

  • Text Styles Manager demo video
    Text Styles ManagerCreates a typography system and applies it to the whole document, variables included.
  • Data Grid Master demo video
    Data Grid MasterTurns a spreadsheet into a data grid built from your own components.
  • Mask Master demo video
    Mask MasterImage masking with adjustable threshold controls.
  • Image to Vector Master demo video
    Image to Vector MasterConverts raster images to editable vectors.

All plugins on my Figma profile

Curiosity has always
made me build things.

  1. At 4

    My father built a customized Sinclair computer for me. I still remember it vividly.

  2. At 14

    I made my first software tools to make my video games more interesting.

  3. At 18

    I explored the internet and built small websites for friends.

  4. At 24

    I studied communication design. My final project became my first startup.

  5. At 35

    I discovered agents as a way to turn more of my ideas into working experiments.

Outside of work, I lift, cook
and stay curious.

  • BodyHeavy weightlifting and time outdoors in nature.
  • MindScience, philosophy and psychology. My favorite channels are Veritasium, Kurzgesagt and Be Smart.
  • HandsGood food and cooking. Woodcraft, drawing and painting.

evgenii.s@posteo.deLinkedIn