Build Design Systems With Penpot Components
Penpot's new component system for building scalable design systems, emphasizing designer-developer collaboration.

uxdesign.cc – User Experience Design — Medium | Fabricio Teixeira
Just the other day I was talking to an experience designer in my team about this simple technique that I have used for years and never really thought about as a proper “technique” — maybe just intuition of someone who has designed more pages than they can remember.
Before jumping into wireframing (and spending time moving gray boxes and blocks of text around on the screen), or even sketching things on paper with the level of polish I would like people to see in my work, at some point I have decided to start my design process with what I later named as storyframes: a hybrid document between a script/story and a wireframe.
The software I use for that?
A text editor.
Google Doc. Or Microsoft Word. Or Apple TextEdit. Anything, really.
The technique works especially well for landing pages, homepages, or long-scrolling pages that are trying to tell a unified, cohesive story. And let’s be honest: these types of pages are becoming more and more popular these days.
The big question I ask myself before jumping into the text editor software to “write” a page is:
How would I explain to a friend, in a conversation or in an email, this thing/topic/product/story I am trying to communicate?
Think about some of the best products and services out there, and the stories their website homepage is trying to tell. Someone has taken the time to carefully write, design and build that page so that you, as a visitor, can understand the message in a quick, digestible and human manner.
Pretty much every page on the web is trying to tell a story.
Stories work pretty well in a script format. Stripping away all the visual clutter can help you focus on the core of the message you are trying to communicate. And text editors are a great tool for that: they are simple, clean, and available in pretty much every device you use everyday as a designer— from computers to tablets to mobile phones.
Stripping away all the visual clutter can help you focus on the core of the message you are trying to communicate.
When you jump from the brief right into the design software of your preference (Sketch, Photoshop, InDesign, Axure, Principle or whatnot), chances are you are going to spend a considerable amount of energy crafting the form before you craft the story.
Even if you are very proficient using that software and even if you keep your wireframes to low fidelity, you are still using mental bandwidth (and a bit of extra time) in defining the form rather than the bare-bones version of what you are trying to say. When you are using design software or even sketching on paper, you are making design decisions (two columns or three columns?) before being 100% certain that part of the story needs to exist on the page in the first place.
Interfaces are stories, and every designer is a storyteller — whether you’re designing a landing page, a product narrative, a signup form, or a chatbot conversation.
Of course story not always supersedes form; it certainly informs it and sometimes precedes it. A few designers will argue that working through the design can help inform the story, and that one aspect feeds the other in a symbiotic manner. True. But the point here is more about where I like to start, and a technique that has worked well for me over the last few years. I’m sure every designer has a different trick.
Storyframes look like a script, with focus on hierarchy and page structure rather than layout or final copy. Here’s a quick example of what the Dropbox homepage would look like in storyframe format:
Storyframes in design: a few lines of text can help you define your page narrative before jumping into design software
A few best practices when writing your page story:
Honestly, the first step is a quick brain dump onto a white, empty text file. Think of each paragraph as a module, and each sentence as an element you will eventually add to your design. The exercise of writing down everything you can possibly say about that product can help you organize your thoughts before you start prioritizing the most important talking points.
I always go back to that initial question: how would I explain to a friend, in a conversation or in an email, this thing/topic/product/story I am trying to communicate?
Usually writing it down takes about 15 minutes and half cup of coffee.
Once you have it all aggregated into a single document, it’s time to trim down the length of your story. Because you are part of the team designing the product, chances are you know too much about how it works and you can get into the weeds too quickly.
“I didn’t have time to write a short letter, so I wrote a long one instead.” — Mark Twain
Take a quick break and a deep breath before you go back to your document and start refining what your users really need to know about it. Think about their context: how are they coming to this page? What do they know about the product at that point, and what is the minimum they need to know before they are able to move forward?
Once you have a first draft, create multiple copies of your document and start playing with its hierarchy: how can you reorder elements to tell different stories, and which of these versions sound more natural to a human? During this exercise you can also play with swapping certain paragraphs and re-introducing some of the content you removed on step 2.
The beauty (and honestly, the goal) of writing the page story before jumping into wireframes, is that it allows you to easily show it to other teams to gather feedback and collect inputs from them. Make sure they understand that’s not final copy, but rather a synthesized version of the page structure.
Only then, you move into wireframes and visual mockups.
In the end, no matter how you and your team decide to design each of the modules, the overall page story remains intact — since you have forced stakeholder alignment from the beginning.
What I like about storyframes (or “page outline”, or “page script”), is how much time it saves me in the end of the day. You can make pretty high-level decisions about the strategy, the flow, and the narrative, without spending time into the weeds of design tools.
When the story is more refined and you have enough stakeholder alignment to confidently move into the next phase, you can start asking yourself more specific design-related questions:
Storyframes before wireframes: starting designs in the text editor was originally published in uxdesign.cc on Medium, where people are continuing the conversation by highlighting and responding to this story.
AI-driven updates, curated by humans and hand-edited for the Prototypr community