# absolute relative

> absolute relative is the brand under which Jelena Racković works as a designer and consultant in the IT industry. Based in Belgrade, Serbia, she is Chief of Product Development at an independent IT company, working on product strategy, UX/UI, design systems and design leadership since 2008.

Website: https://absoluterelative.me/
Contact: jrackovic@gmail.com · WhatsApp +381 69 218 3808 · https://www.linkedin.com/in/rackovic/

## Services
- Product strategy: deciding what is worth building, for whom and in what order.
- UX/UI: research, flows and interfaces for complex products, tested in clickable HTML prototypes.
- Design systems: tokens, components and themes shared by design and code.
- Design leadership: leading UX and frontend teams from idea to launch.

## Selected work
- A single source of truth – the foundation for many products. A large-scale system: one token library behind a public portal and the central system that runs it. Design system, tokens, UX research and direction.
- Building trust that extends to a partner’s own clients. An embedded design partner to three software studios, for their brands, their products and their clients: augmented reality, mobile, systems and branding.
- From day zero to this very day – working with partners side by side. Since 2011, the brand and event partner to Conference Republic: identities, websites, print, digital stages and copy for Sinergija, the Consumer Rules Summit, GDi, Microsoft events and the Science Fund.
- Leaving a trace – the foundations are still in place years later. Designer of Agremo’s software from its first day; the company has since grown across several continents, and the product foundations remain.

## Where I come in
- Transformation: modernising a product or process that outgrew itself.
- From blank page to launch: a new product, from nothing to release.
- Reorganisation: untangling teams, processes and systems.
- Startup mode: shipping fast without paying for it later.
- Refresh: a visual or UX refresh, without a rebuild.

## Solutions
Web applications, cross-platform systems, mobile apps, CMS and editorial tools, design systems, brand identities, prototypes.

## Projects that suit me
Projects with many stakeholders, strict rules, several products that must work as one, or a team that needs clear direction. Rebranding companies and brands is a particular favourite.

## Journey
- 2008: Graduated in applied arts and started as a graphic designer at an agency (identities, brochures, posters).
- 2010: Moved to an IT company; web design and branding.
- 2011: Founded the first agency, the forerunner of absolute relative.
- 2012–2015: Government and reform projects; clients from Germany, the US and the region.
- 2017: UX/UI at full scale: cross-platform systems, mobile apps, mentoring teams for international clients.
- 2020: Consulting and shaping brands through absolute relative, and leading projects and people from idea to delivery.
- 2023: Leading a UX and frontend team, supporting delivery.
- 2026: Directing product development.

## FAQ
### What is absolute relative?
absolute relative is the brand under which Jelena Racković works as a designer and consultant in the IT industry. She founded its forerunner in 2011. Today she is also Chief of Product Development at an independent IT company in Belgrade, Serbia, where she leads product strategy, UX/UI, design systems and the teams behind them.

### What services do you offer?
I work across the whole life of a digital product: deciding what is worth building, designing the interface, and setting up the design system that design and code share. I also lead UX and frontend teams, build clickable prototypes and write the documentation larger projects depend on. And I have never stopped being a graphic designer, so brand identities and print are still part of what I do.

### What kind of projects suit you best?
Projects with a lot going on: many stakeholders, strict rules, several products that have to work as one, or a team that needs a clear direction. I have done that for public institutions, software companies, event organisers and start-ups alike, and companies or brands ready for a rebrand are a particular favourite of mine. The common thread is always the same: a complex problem that needs a clear system, a sense of direction and a fair amount of creativity.

### How does a project with you start?
With a short message about what you are working on, or simply where you feel stuck. It is perfectly fine if you are not sure yet what you need; many good projects start exactly that way. We talk it through, and then, in short iterations, we work out what is worth doing and in what order, so the scope grows out of real ideas rather than guesses.

### How long does a project take, and how is the price set?
It depends on what we are building. With today’s tools, a clickable prototype often takes far less time than people expect, while a complex platform naturally takes longer, so I would rather give you an honest estimate once I understand the scope than a number in advance. As for the price, I am flexible: we can work from an effort estimate, by the hour or within a fixed budget, whichever suits the project and the way you work. Either way, we agree on what is included before we start.

### Do you work with clients outside Serbia?
Yes. Over the years I have worked with clients across the region, in Germany, Switzerland, the US and the United Arab Emirates, and even on a product for the Japanese market. Location has never been a limitation: most of that work was done remotely, with shared documentation, so everyone knows what has been decided and what comes next. And I always look forward to projects beyond Serbia.

### Can you improve an existing product instead of starting over?
Usually yes, and it is often the wiser choice. I look closely at what is already there, the flows, the components and the places where people get stuck, and just as closely at the context: the kind of product it is, its market and what it is meant to achieve. Whether there is a real system, none at all or something that only looks like one, it can all be worked out. We then change what matters most first, while the team and the users carry on working.

### Can you introduce a design system into a product that already exists?
Yes, and it rarely requires stopping anything. I start with what the product already uses, give the recurring decisions names as tokens, and turn the most repeated parts into shared components. They then replace the old ones gradually, alongside ongoing development, until design and code share a single source of truth and every new screen is quicker to build than the last.

### Do you also prototype and work with the rest of the team?
Yes. These days, quick iterations in clickable prototypes matter more than ever: an idea tested in a real browser often settles in an afternoon a debate that could run for weeks. Careful work on the actual design is still my first love. I also lead designers and frontend developers and guide analysts and project managers, so handoff and delivery are part of my everyday work, and I would much rather someone asked me a question than built something blindly.

### What makes your approach different?
I start from the problem rather than the screen. I came to product design through graphic design and later took on teams and delivery, so I tend to see a brand, an interface, a system and the people building it as one problem rather than four. I also write decisions down as we go, so you always know what has been agreed and why, and the harder the task, the more interesting it usually becomes.

## Case studies
- [Agremo: product foundations that last](https://absoluterelative.me/work/agremo/): Designing Agremo’s software from its first day. The start-up has grown across several continents, and the product foundations are still in place.
- [Conference Republic: brand and events](https://absoluterelative.me/work/conference-republic/): Fifteen years of brand and event design with Conference Republic: Sinergija, the Consumer Rules Summit, GDi Solutions Day and more, from identity to venue.
- [One source, many products](https://absoluterelative.me/work/one-source-two-products/): A token-based design system for a very large public portal and the central system behind it: one source of truth, reusable components and a library for the…

## Field notes
Short essays on design systems, product work, AI and leading teams. Index: https://absoluterelative.me/notes/
- [A design system is a product, not a Figma file](https://absoluterelative.me/notes/a-design-system-is-a-product/): Why I run a design system like a small product, and why it is really the digital heir to brand standards: organisation, not rigidity.
- [A prototype for a pitch: what to show, what to skip](https://absoluterelative.me/notes/a-prototype-for-a-pitch/): When a pitch is coming, there is never enough time and always too much to show. Why I build one flow that works end to end, and skip the rest.
- [Adding a design system to a product that already exists](https://absoluterelative.me/notes/adding-a-design-system-to-an-existing-product/): How to introduce a design system into a live product without stopping development: start from what exists, name the recurring decisions, and replace the old…
- [AI is a tool like any other: what it changes in design work, and what it doesn’t](https://absoluterelative.me/notes/ai-is-a-tool-like-any-other/): Every new tool is sold as the end of the profession. What AI genuinely changes in design work, and what it never will.
- [Before the first screen: the questions I ask every new client](https://absoluterelative.me/notes/before-the-first-screen/): The few questions I ask every new client before designing anything, and why “just point at what you mean, then let me work” is often the most useful brief.
- [Build, park or drop: letting go of ideas without losing face](https://absoluterelative.me/notes/build-park-or-drop/): Why I would rather drop more ideas than fewer, how build, park and drop work in real product situations, and why the skill matters even more now that AI…
- [Changing my mind on purpose: why being wrong early is cheaper](https://absoluterelative.me/notes/changing-my-mind-on-purpose/): Teams often defend their first ideas long after they stop working. Why I make changing my mind a planned step, not a failure.
- [Claude, Figma, Claude, Figma, coffee: how AI really fits into my design work](https://absoluterelative.me/notes/claude-figma-claude-figma-coffee/): How AI actually fits into my design work: a tool that speeds things up and helps clients decide sooner, not a replacement for judgement or real-world…
- [Creativity isn’t a prompt: protecting thinking time when AI does the typing](https://absoluterelative.me/notes/creativity-isnt-a-prompt/): AI produces so quickly that thinking time quietly disappears. Why I protect slow thinking, sketch and wait first, and only then let the tool help.
- [Running delivery and R&D in parallel without starving either](https://absoluterelative.me/notes/delivery-and-rnd-in-parallel/): Delivery always comes first. From practice: how small pieces, light coordination and creative leadership let R&D move alongside it without anyone feeling…
- [Design tokens explained to a project manager in five minutes](https://absoluterelative.me/notes/design-tokens-for-project-managers/): A five-minute way to explain design systems and tokens to any project manager, and why the design phase is where a project gets cheaper or more expensive.
- [Mental health beats speed: designing at a pace you can keep](https://absoluterelative.me/notes/designing-at-a-pace-you-can-keep/): Nobody wins against the speed of this industry, and nobody should feel smaller for it. Why good work needs pauses, and how to find a pace you can keep for…
- [Designing for people who didn’t choose your product](https://absoluterelative.me/notes/designing-for-people-who-didnt-choose-your-product/): When users can’t switch to a competitor, bad UX quietly becomes their daily cost. Why I design public services and internal tools as if people could leave…
- [Designing public services when the rules can’t change](https://absoluterelative.me/notes/designing-public-services/): What years of government and public-sector projects taught me: the rules rarely block progress, indecision does, and a clear vision told well moves…
- [Estimating design work so people can plan around it](https://absoluterelative.me/notes/estimating-design-work/): Design is not engineering, and it doesn’t fit neatly into hours. How I still give estimates people can plan around: a three-dimensional map of the work, and…
- [Features are the last step, not the first](https://absoluterelative.me/notes/features-are-the-last-step/): Teams jump straight to features and end up arguing about solutions. Why I agree on the goal and the problem first, and only then compare several possible…
- [Getting developers to actually use the design system](https://absoluterelative.me/notes/getting-developers-to-use-the-design-system/): Winning developers over to a design system is hard at first. Once they start, they never go back.
- [Ideas without egos: deciding together when everyone has a favourite](https://absoluterelative.me/notes/ideas-without-egos/): Ego kills more product ideas than a lack of knowledge. Why my favourite idea doesn’t matter to the product, what a CPO does about it, and how failing…
- [Immature teams, mature teams: what each one needs from a leader](https://absoluterelative.me/notes/immature-teams-mature-teams/): Teams stuck in conflict get labelled as bad teams, when they are often just early in their development.
- [Junior vs senior designers: the myths both sides believe](https://absoluterelative.me/notes/junior-vs-senior-designers/): What fifteen years of mentoring taught me about juniors and seniors: the myths both sides believe, and how juniors grow into people you can trust with big work.
- [Keeping a design system alive: ownership, debt and small regular fixes](https://absoluterelative.me/notes/keeping-a-design-system-alive/): Why design systems fade instead of failing, and how one clear owner, visible debt and small regular fixes keep a system alive without big rewrites.
- [Lazy is not the same as efficient: where shortcuts stop helping](https://absoluterelative.me/notes/lazy-is-not-the-same-as-efficient/): Shortcuts feel productive until the thinking gets skipped. Why I automate the boring parts of design work, and never the judgement.
- [Leading a UX and frontend team across many parallel projects](https://absoluterelative.me/notes/leading-ux-and-frontend-across-projects/): “That’s how it was in the design”: why designers and developers misread each other, why the blame so often lands on design, and what organisations and both…
- [Naming design tokens so people can still use them two years later](https://absoluterelative.me/notes/naming-design-tokens/): Why every design system I build starts with a written token registry, and how reading it teaches the whole team the naming order and semantics of tokens.
- [One client asked for it. Does the market want it?](https://absoluterelative.me/notes/one-client-asked-for-it/): A single client’s request can feel like market demand, until nobody else buys it. How I check that a problem repeats across clients before turning it into a…
- [Why it’s hard to build one product inside a company full of products](https://absoluterelative.me/notes/one-product-inside-a-company-full-of-products/): When every product competes for the same people and the same roadmap, none of them gets real focus.
- [One product, two screens: designing a mobile app and the web app behind it](https://absoluterelative.me/notes/one-product-two-screens/): When the mobile app gets the spotlight, a central system quietly does the heavy lifting. How I design those systems to be affordable now, scalable later, and…
- [One token set, many brands: theming a platform for multiple clients](https://absoluterelative.me/notes/one-token-set-many-brands/): How a well-built token library lets one platform serve many clients, and why, done properly, a new brand can come down to two colours and a corner radius.
- [Redesigning a media CMS without stopping the media company](https://absoluterelative.me/notes/redesigning-a-media-cms/): Why redesigning a media CMS and portal is never just a new system: it has to fit how editors really work, it needs a firm lead, and it has to respect the…
- [Research once, build for months: breaking the habit](https://absoluterelative.me/notes/research-once-build-for-months/): Teams often research once at the start, then build for months on assumptions that quietly expire.
- [Revenue is too late: measuring what the team can actually move](https://absoluterelative.me/notes/revenue-is-too-late/): Teams are often judged on revenue they can’t directly influence. Why I pick the user behaviour that drives revenue and measure that instead.
- [Sets that don’t know about each other: building on a client’s design system](https://absoluterelative.me/notes/sets-that-dont-know-about-each-other/): What a vendor should do when the client’s design system has no registry and the naming falls apart: point it out, offer to help, and start fixing it together.
- [Shifting to AI: not the future, but a present that came from the past](https://absoluterelative.me/notes/shifting-to-ai/): We keep calling AI the future and reacting late to a present that is already here. Why I learn it properly, and bring what it can’t: thinking beyond what is…
- [Shipping under pressure when the process gets in the way: skill or style?](https://absoluterelative.me/notes/shipping-under-pressure/): The deadline is fixed, but analysis and approvals keep growing. How I cut the process down to what protects quality, and say no to the rest.
- [Small test, big bet: checking the risky part before building](https://absoluterelative.me/notes/small-test-big-bet/): Teams often build a whole feature to test one shaky assumption. How I find the riskiest bet in an idea and test it in days rather than months.
- [Stop comparing, start framing: the only angle that matters](https://absoluterelative.me/notes/stop-comparing-start-framing/): Comparing your work with everyone else’s is the quickest way to lose the thread. The only angle that matters is the problem: which one you are solving, and how.
- [Stop judging, start supporting](https://absoluterelative.me/notes/stop-judging-start-supporting/): Everyone feels invited to judge, and almost nobody offers support. Why I try to be critical of the work when it helps, and supportive of the person always.
- [Strict but fair: how I give design feedback](https://absoluterelative.me/notes/strict-but-fair/): How I give design feedback: honest about the work, respectful of the person, specific enough to act on, and always tied to the problem rather than to taste.
- [The designs I loved and killed, and what they taught me](https://absoluterelative.me/notes/the-designs-i-loved-and-killed/): Two very different projects, a national tax reform and a small logo redesign, and what they taught me about letting go of the design itself and caring about…
- [The universal soldier: domain knowledge plus range beats a narrow specialty](https://absoluterelative.me/notes/the-universal-soldier/): Why designers who combine deep domain knowledge with real range matter more than ever, and why range only works if a team knows when to scale beyond one person.
- [Theory of nothing: an empty set is still a set](https://absoluterelative.me/notes/theory-of-nothing/): Why a blank page is the best place to start in design: an empty set is still a set, full of ideas that research, your voice and early checks shape.
- [Too many managers, too few makers: who actually does the work?](https://absoluterelative.me/notes/too-many-managers-too-few-makers/): Coordination layers grow while a handful of people build everything. Why management should stay close to the craft, and why makers’ time needs protecting.
- [Too much input, too little filter: choosing sources you can trust](https://absoluterelative.me/notes/too-much-input-too-little-filter/): We read everything, check nothing and repeat what sounds right. Why I keep fewer sources, check them, and leave time to think about what I read.
- [When a developer thinks they’re the designer, and how to work it out together](https://absoluterelative.me/notes/when-a-developer-thinks-theyre-the-designer/): When a developer redesigns a screen on their own, the argument is rarely about design. It is about two people solving different problems.
- [When AI is mandatory: focus, memory and the cost of doing six things at once](https://absoluterelative.me/notes/when-ai-is-mandatory/): Why working with AI on six threads at once leaves nothing in memory, why reading and revising still matter, and why the person, not the tool, owns the facts.
- [When everything looks the same: AI, the flat design déjà vu, and why real-world thinking wins](https://absoluterelative.me/notes/when-everything-looks-the-same/): AI-generated interfaces are converging on one look, much as flat design once did. Why sameness always peaks and passes, and why real-world thinking is what…
- [No time to think, no opinion to give: when pressure kills judgment](https://absoluterelative.me/notes/when-pressure-kills-judgment/): Why pressure quietly erodes judgment, and how I handle a crisis: as few decisions as possible, none of them impulsive, with a quick look at the whole picture…
- [When to say no to a new component](https://absoluterelative.me/notes/when-to-say-no-to-a-new-component/): Every new component is a long-term commitment. How I decide when to say yes and, more often, when to say no, and why that call needs both authority and…
- [Why B2B finance dashboards fail, and how to fix one](https://absoluterelative.me/notes/why-b2b-finance-dashboards-fail/): Most B2B finance dashboards show every number and answer no question. How I fix them: start from the decision the user has to make, then show only what…
- [Why I sometimes let a product ship without a design system or tokens](https://absoluterelative.me/notes/why-i-sometimes-ship-without-a-design-system/): Design grew out of art, and art doesn’t take fences lightly. Why experience lets me leave some products loose, and when I would never do it.
- [Why I stopped asking clients what they want](https://absoluterelative.me/notes/why-i-stopped-asking-clients-what-they-want/): Waiting for clients to say what they want makes a partner reactive. Why I lead with a proposal, listen, iterate and always bring a result, and why that makes…

## Languages
The whole site is available in English, Serbian (https://absoluterelative.me/sr/) and German (https://absoluterelative.me/de/): the homepage, all case studies and all field notes (https://absoluterelative.me/sr/notes/, https://absoluterelative.me/de/notes/).