Designing From Content: What Migration Projects Taught Me About UX
What happens when the starting point of a design is not a screen, but a pile of approved content?
Designing From Content: What Migration Projects Taught Me About UX
What happens when the starting point of a design is not a screen, but a pile of approved content?
A lot of UX discussions begin with users, flows, wireframes, and research.
In my professional work, I have often started somewhere much less glamorous:
content.
A migration project can sometimes arrive with a clear template and approved copy. Other times, there may be very little visual direction at all.
You might receive headings, paragraphs, links, supporting information, and requirements, and then have to figure out how all of that should become a usable page.
This kind of work changed the way I think about content and interface design.
I stopped seeing content as something that is simply placed into a layout. I started seeing it as one of the things that creates the layout.

From approved content to responsive UI.
The design problem starts before Figma
When I receive content, I do not want to immediately create frames and start placing text into them.
First, I need to understand what the content is doing. What is the main message? Which information is essential? What belongs together? What should users see first? What is supporting information? Are there sections that naturally form a hierarchy?
This is where content begins influencing the interface. A long section of information may need stronger grouping. A short, important message may need more visual emphasis. Related information may need to sit together instead of being spread across multiple areas.
The structure of the page starts emerging from the structure of the content.
Sometimes the template comes first
Projects do not always begin with a blank canvas. Sometimes a predefined template already exists. That gives you structure, but it also introduces a different design problem.
The question becomes:
How do I make this particular content work within this particular template?
A template might define the available sections, components, or general page structure. But content does not always fit neatly into those boundaries. It can be longer than expected. A section may need more hierarchy. A component may not communicate the information effectively. A page may feel visually unbalanced even though every required section is technically present.
So I have to work between two things: what the template allows and what the content needs. That space between them is where a lot of the design decision-making happens.
Content hierarchy becomes interface hierarchy
This was one of the biggest lessons for me. Good visual hierarchy does not begin with font sizes and colors. It often begins with understanding the information itself. Before deciding how something should look, I need to understand how the information relates.
What is primary? What is secondary? What can be scanned? What requires closer reading? What information belongs in the same group?
Once those relationships are clear, the UI decisions become easier.
Typography, spacing, components, cards, sections, and layout all become tools for expressing that hierarchy.
The visual design is supporting the information architecture rather than decorating it.
Designing when the content cannot change
This becomes particularly interesting when working with approved content. There are situations where rewriting the copy is not part of the designer’s role. The content has already gone through its own process. So the design has to work with what is there.
That means looking for opportunities elsewhere. Can the information be grouped better? Can the hierarchy be clearer? Can spacing make a dense section easier to scan? Can a different component make the relationship between pieces of information more obvious? Can the responsive layout prevent the content from becoming overwhelming on smaller screens?
Sometimes the words stay exactly the same, but the experience becomes much clearer because the surrounding structure changes.
Responsive design becomes part of the content problem
Content that looks manageable on desktop can behave very differently on mobile.
A heading wraps. A paragraph becomes much taller. Two columns become one. Cards stack. Buttons move.
Spacing that felt balanced on desktop may suddenly feel excessive. This means responsive design cannot always be treated as a final resizing exercise. The content itself needs to be considered across different screen sizes. A layout that works beautifully for short content may break when the real copy is longer. A component that looks elegant in one arrangement may become awkward when everything stacks vertically. Designing with real content forces these questions earlier.
These type of projects taught me to think structurally
The more of these projects I work on, the more I think it as a process of transformation. The starting point might be: existing content or existing content + template or existing content + an existing experience
The job is to turn that material into a structure that people can actually use. That means moving through questions like:
What information exists? How is it related? What hierarchy does it need? What structure supports that hierarchy? Which components fit? How should it behave responsively?
The visual design comes out of that thinking.
What these projects have taught me
My work has made me more comfortable designing without a perfect starting point. It taught me that a designer does not always receive a neatly packaged problem.
Sometimes you have to discover the structure inside the inputs you are given. That might mean working from content. It might mean adapting a template. It might mean translating requirements into page structure. And sometimes it means balancing all three.
Much of my professional work is confidential, so I cannot publicly show the original project screens, content, or client details.
But the experience has given me a lesson I can share:
Content is not just material that fills a design. It is one of the inputs that shapes the design itself.
That is something I now carry into every content-heavy interface I work on.
Note: Project details and examples have been generalized to respect client confidentiality and NDA requirements.
메타데이터
- post_id
- fe97d05b93da
- slug
- designing-from-content-what-migration-projects-taught-me-about-ux-fe97d05b93da
- url
- https://medium.com/@bhavanashreem/designing-from-content-what-migration-projects-taught-me-about-ux-fe97d05b93da
- canonical_url
- https://medium.com/@bhavanashreem/designing-from-content-what-migration-projects-taught-me-about-ux-fe97d05b93da
- author_url
- https://medium.com/@bhavanashreem
- status
- ok
- fetched_at
- 2026-10-03 05:13:49