large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<a href="http://ift.tt/2r3Dc7x">uxdesign.cc &ndash; User Experience Design &mdash; Medium</a> | Fabricio Teixeira 
<h4>Browsing through a well-crafted interface is like reading a great story (or flipping through a great comic book). As designers, why are we not incorporating screenwriting techniques more often into our process?</h4>
<img alt="" src="http://ift.tt/2ovvVNZ">
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:
<blockquote>How would I explain to a friend, in a conversation or in an email, this thing/topic/product/story I am trying to communicate?</blockquote>
<img alt="" src="http://ift.tt/2j2W1jS">
<h3>Interfaces are stories</h3>
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.
<ul>
<li>The <a href="http://dropbox.com">Dropbox</a> homepage is telling a story about what Dropbox is, why it exists, and how it fits your life.</li>
<li>The <a href="http://ift.tt/14JUXsL">NY Times</a> homepage is telling a story about what is happening in the world today, according to the NY Times’ POV.</li>
<li>The <a href="https://www.airbnb.com/">AirBNB</a> homepage is telling a story about what AirBNB is, with examples of services it provides.</li>
</ul>
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.
<blockquote>Stripping away all the visual clutter can help you focus on the core of the message you are trying to communicate.</blockquote>
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.
<blockquote>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.</blockquote>
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.
<img alt="" src="http://ift.tt/2j2W1jS">
<h3>Storyframe example: the Dropbox homepage</h3>
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:
<img alt="" src="http://ift.tt/2r3ABe0">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:
<h4>1. Start by writing it all down</h4>
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.
<h4>2. Keep it short</h4>
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.
<blockquote>“I didn’t have time to write a short letter, so I wrote a long one instead.” — Mark Twain</blockquote>
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?
<h4>3. Play with multiple stories</h4>
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.
<h4>4. Shop it around</h4>
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.
<img alt="" src="http://ift.tt/2s1DUzN">
<h3>Storyframes: the lowest fidelity possible</h3>
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:
<ul>
<li>What is the best way of displaying that information?</li>
<li>Which parts of the text can be grouped in modules?</li>
<li>Which parts of the story can you replace with images, videos, or short animations instead?</li>
<li>Which parts of the story can you complement with those same resources?</li>
<li>Which specific proof points do you want to display to back up your arguments?</li>
<li>Which actions do you expect people to take after going through your page story?</li>
</ul>
<img alt="" src="http://ift.tt/2j2W1jS"><iframe src="http://ift.tt/2iFGGW9" width="800" height="400" frameborder="0"><a href="http://ift.tt/2h0f00F">http://ift.tt/2h0f00F</a></iframe><img src="http://ift.tt/2r3QjWn" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2s1zWXG">Storyframes before wireframes: starting designs in the text editor</a> was originally published in <a href="https://uxdesign.cc">uxdesign.cc</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Storyframes before wireframes: starting designs in the text editor

Storyframes before wireframes: starting designs in the text editor

Browsing through a well-crafted interface is like reading a great story (or flipping through a great comic book). As designers, why are we not incorporating screenwriting techniques more often into our process?

Top Stories