Ericsson
UX Designer on dense private-5G software, where my job was making complex, technical tools clear for expert users.
- No.
- 01
- Year
- 2025–26
- Medium
- Enterprise software, private 5G
- Role
- UX Designer and Scrum Master
- Where
- Enterprise Wireless Solutions, Gothenburg. One of twelve designers.
- Worked with
- Product and engineering, closely and daily
- Status
- Adopted team-wide
The problem
Private 5G software is dense: a lot of state, a lot of configuration, and a lot of things that go wrong in ways only an expert would recognise. The screens were rarely the hard part. The hard part was the space between design and engineering, and that is where all three of these cases live. Each one stands on its own.
The work is under NDA, so what you see here is the method and abstracted diagrams, not the real screens.
What I did
01a · AI-ready Figma deliveriesScreens show how it looks. Specs say how it behaves.
Our developers used AI to turn Figma into code, and it kept building the annotations instead of the interface.
- My part
- Research, an audit framework, and the delivery-for-ai skill
- Result
- Adopted as the team-wide standard
Our design files were built for humans: screens buried under sticky notes, arrows, colour overlays and rationale sitting on top of the interface. The AI could not tell the difference, so it tried to build the sticky notes too. As one developer put it, “Annotations confuse the AI.”
Before 27 screens · 148 annotations · one flat canvas
After 17 screens in sections · 3 specs
I documented two real developer workflows to see where it broke, opened a Slack channel so feedback kept coming, and read about twenty case studies from teams like Atlassian, Spotify, Miro and Figma. The pattern was the same everywhere: structured input produces better output. To say how bad our files were, I wrote a small audit framework. It is my own, not an industry standard, but it let us talk about a file being more or less AI-ready instead of just “messy”.
| No. | Dimension | Score |
|---|---|---|
| 01 | Structural separationAre delivery screens on their own page or section, or mixed in with everything else? | 012 |
| 02 | Naming conventionCan an AI tool tell annotations apart by name, for example a handoff/ prefix? | 012 |
| 03 | Component semanticsDo frames and layers have meaningful names, or "Frame 47"? | 012 |
| 04 | Interaction dataIs behaviour machine-readable, or trapped in arrows and tables? | 012 |
| 05 | Noise ratioWhat share of the nodes are annotations rather than real interface? | 012 |
Then I built a Kiro skill, delivery-for-ai. Point it at a polish page and it produces a clean delivery page in the same file: screens on the left, organised by feature; a few structured notes on the right about behaviour, style tokens and what changed. The rule that made it work was keeping those notes strictly about behaviour. When they described the interface too, the AI started inventing things.
Screens
show what it looks like
Specs
say how it behaves
- Interaction behaviour flows, states, conditions
- Style tokens theme, colour, type, components
- Changes summary what is new, what changed
I tested it with a developer over four rounds, fixing what broke each time. It went from the AI inventing a toolbar that didn’t exist to the developer saying “this is pretty good, the issues are on my side now.” Then I wrote it up as a shared standard, so it wasn’t just something I did on my own files.
01b · Build better togetherInvite one person one step earlier.
Design and development worked in sequence instead of together, so Frida Edstam and I built methods people could start using the next morning.
- My part
- Co-creating the methods with Frida Edstam, and the talk
- Result
- A talk at the Ericsson Developer Conference, and a printed handout for everyone in the room
PM to design, design to front-end, front-end to back-end. Everyone reacted to what the person before them had already decided, and nobody else was in the room when the decision got made. What we asked for is smaller than it sounds: invite one person from another discipline one step earlier than usual. You are giving them context, not extra work.
The handoff trapEach discipline reacts to the stage before it. The way out: one person, one step earlier.
- ProductFeature idea
- DesignerDesign studyBrainwriting
- DesignerLo-fi designMini-demo
- DesignerHi-fi designOne-person invite
- Front-end · back-endDevelopUX + front-end pairingMini-demo
- QA, everyoneTestUX bug bash
- TeamRelease
- EveryoneIterateUX improvements channel
Printed · A4 · one page
A copy for everyone in the room at the Ericsson Developer Conference, so people could start the next morning without us.
Take onePrinciples are easy to nod along to and impossible to act on, so every method came with a time box, a group size and a source. “Collaborate more” is not something anyone can put in a calendar.
Build better together
Practical methods and habits for cross-discipline collaboration · EDC 2026
Co-creation methods
- Brainwriting
- Write the problem statement visibly
- Everyone writes ideas in silence · 5 min
- Rotate papers, build on others' ideas · 3 min
- Discuss the most promising directions
Silent writing removes loud-voice bias and production blocking. Groups generate 20% more and better ideas than brainstorming.
- UX + front-end pairing
- Designer and developer, same screen
- Walk through the real implementation
- Small issues: fix on the spot
- Bigger issues: write the ticket together
95% of developers enjoy pairing more, with 15% fewer defects. Removes suspicion between disciplines.
- UX bug bash
- Break the experience, not the code
- Behaviour: does it feel right?
- Copy: clear and consistent?
- States and edge cases: empty, loading, error, long text, zero items
Applies the shift-left principle to experience quality. Developers notice what designers miss.
- Design Studio
- Everyone sketches 6–8 ideas · 5 min
- Present and critique · 2–3 min each
- Sketch again with the feedback · 5 min
- Converge on the strongest directions
Cross-disciplinary sketching surfaces unknowns a designer alone would miss. Recommended by NN/g.
- Crazy Eights
- Fold paper into 8 panels
- Sketch 8 ideas in 8 minutes
- Present all the sketches
- Dot-vote on the strongest
Time pressure forces quantity over quality, producing more creative output. A core exercise in the Google Design Sprint.
- The one simple ask
On your next feature, invite one person from another discipline one step earlier than usual, and try one small method: a brainwriting session, a mini-demo, a pairing session.
Daily habits
- Public channels
Feature or design decision? Shared channel, not a DM. Knowledge stays visible and decisions keep their context.
About the product? Shared channel.
- Mid-sprint demos
Something visual working, even rough? Invite the designer for 15 minutes. It catches misalignments while they are still cheap to fix.
Show early. Fix cheap.
- One-person invite
Every share-out or review: invite one person from another discipline. A developer in a design review. A designer in planning.
One person, one step earlier.
- UX improvements channel
Anyone reports UX issues: confusing labels, slow transitions, missing states. Designers triage them into a backlog.
Anyone posts · triage · backlog.
Workshops are the easy part. None of it sticks unless ordinary days change too, which is why half the handout is daily habits. We gave it out at the conference so people could start without us in the room, and that mattered more to me than the talk: a talk is forty minutes, the handout is still on people’s desks.
01c · Generative UI for dashboardsDesign the rules, not the screen.
Our dashboards hold far more telecom data than any static layout can show, so in a hackathon we designed one that assembles itself.
- My part
- The card component, the specs, the prototype and the proposal, in a Tweak Week team with three other designers and a front-end developer
- Result
- A US back-end team used the component to display live data
What someone needs to see depends on their role and on what the network is doing right now, and building a new dashboard for every case is slow. So the proposal was a canvas and an assistant. The assistant assembles a whole layout from context, cards arrive pre-filled, and you steer it two ways: ask in the chat, or act on the cards yourself.
- I’ve laid out a dashboard for your role, and I’m watching it live. Ask for a change, or edit the cards directly.
- Whole layouts, assembled from context in one go.
- Consistent containers: content varies, the card shell doesn’t.
- AI suggests, the person decides: pin, keep or dismiss any card.
- Transparency: every card shows its source and freshness.
Generative UI is easy to get excited about, so before designing anything I checked what had actually been shown. People prefer dynamic card interfaces to chat by roughly 72% (Stanford and Georgia Tech, 2025). Generated interfaces match expert designs about half the time, and constrained component catalogs beat free-form generation (Google Research, 2025). Dashboards should adapt to how expert the user is (IEEE Drillboards, 2025). So the assistant would not draw screens freely; it would assemble our own cards.
That meant the card had to work first. It was a fixed-size box that broke the moment a layout became dynamic, so we rebuilt it as one content-driven component that responds to whatever width the grid gives it.
Static card fixed width, fixed height
- Breaks the moment a layout becomes dynamic
- Limits what data can be shown at all
Dynamic card width and height follow the content
- Responds to whatever width the grid gives it
- One component instead of a set of special cases
Then we built it end to end, from the Figma component to live data, so the specs had to hold up at every step. A front-end developer adapted the real component, and a back-end team in the US used it to show live data and graphs.
- 01Card componentBuilt in FigmaDesign team
- 02Component specMarkdown, versioned in GitLabDesign team
- 03HTML prototypeGenerated straight from the specTo check the spec held up
- 04Real componentAdapted by a front-end developerLive data from a US back-end team
How it went
A developer and a US backend team shipped real code from my specs.
Frida Edstam and I turned our design–dev methods into a talk at the Ericsson Developer Conference.
Tested with a developer over four rounds before it became the standard.
In all three, the developers were in it from the start.
What I learned
Screens show what it looks like. Specs say how it behaves. Mixing them broke our AI-readability.
My job is shifting towards defining constraints and judging what comes back.
Clean, organised input produces better code with fewer mistakes.
Clean, organised input produces better code with fewer mistakes. That sounds obvious written down, but it changes what a design deliverable is for. You end up writing for two audiences at once, humans and AI agents. Version control and specs are quietly becoming design tools, and the valuable part of the job shifts towards defining the constraints, then judging what comes back.
UX is moving from designing screens to designing systems of rules.