I’ve always been a storyteller at heart. Whether producing a show or writing, my passion was always giving people a story to follow. I’ve found joy in programming coming from the same place. While most applications don’t include a story in the traditional sense, there is still a trail to leave. I like to build new applications starting at this point. When developing a concept a good question to ask is ‘What is the story of the user who would want this application?’ During my last build, I realized how important the story continues to be through the entire process. Not just the story that leads a user to an application, but the story of the user while using the application as well. For me, this became a map. An ugly, ugly map. I am a storyteller, but not an artist.
My name is Sebastian and I'm a recovering screenwriter
If you decide you want to write a screenplay (an unfortunate ailment that affects thousands a year) you'll find yourself with as many different ways to plan your script as there are people trying to write scripts. I know because I've written several myself, and over many years formulated my own way of doing the prep work.
I'm pretty proud of some of my breakdowns. I use a large piece of sketch paper, rulers, carefully printing by hand an easy-to-follow guide. I know that if I can complete the breakdown, I can write the story. I can show them to others and have them follow along. I can use them as examples to teach others my process.
But getting there took several years. My first few attempts? Crazed scribbles across pages of notebook paper, entire sections scratched out and illegible notes written into margins. Scholars will continue to debate exactly which language some of it might be for decades to comes. Figuring out your perfect method takes time and error. But in the end, I came out with something that was not helpful to the writing process but invaluable.
I find myself in the midst of a very similar process for planning out new applications. I've seen many examples of how others plan and map out their sites, but I know that it will take trial and error for me to figure out what it is I need to be successful. And it's not very pretty, but it's crucial.
Pirate : Treasure map :: Programmer : diagrams.net
There are of course people who have no trouble holding everything in their head or people who can follow along with their own hasty notes that skip around with no reference to what component or logic they are noting. I envy them and send my best wishes to their team members who do not possess this same skill.
For the rest of us, please trust me when I say: you need a guide. And as my own projects get bigger and more complex I find the only thing that can untangle my thoughts and help me navigate and focus is a visual map. At some point, I hope to get to the same point as my script breakdowns, something organized and clean that can help translate my thoughts to others as well as organizing them for myself.
For now, I have this:
This page is the only thing that kept me sane while building this application. If you squint, you can see the user story I was trying to build.
The initial landing page branches off into what is essentially my navbar, and then I’ve broken down those into the components that are included in those containers, with a few arrows to show how a user might get from one to another.
I’ve come back to this when I’m lost - that’s why I like to call it a map. “What am I doing, what is my goal right now?” is a question I find myself asking whenever I get frustrated with a bit of code. I think everybody has had a moment where you get so caught up in a bug that you forget what the original goal was, and sometimes the bug you working out is in a bit of code you don’t even need! The map helps to get me back on track and reminds me to put myself in the user’s shoes. What is my user expecting, what will they want to do from this point?
Become the guide
Finally, on the subject of putting yourself in the user’s shoes, if you hand a site over, even one with a ton of great and interesting functionality, a user isn’t going to know what to do on their own. A good site tells the user exactly what to do. Think of any social media site. There is usually a big log-in component right on the main page, and once a user is logged in that is replaced with whatever posting option that site has. It’s always front and center, usually prompted as well (though less so these days, but remember the OG facebook “I think…” prompts?). Users want to be told what they should do and what they can do, and in this way, you can lead your user through the application. Navbars are only part of the way to do this, but adding in prompts is better. Never underestimate how obvious your functionality is. “New Post” isn’t as dynamic as “Create a new post”. Try to phrase all functionality as a call to action, you can always pare them down later (a ‘like this post’ button can easily just be labeled ‘like’ thanks to the popularity of the feature).
Your user doesn’t get your map when they come to the site, so you should work to translate that map into a guide. Design can help a lot here, making the more important component stand out on a page, but how they are labeled can be just as important.
Epilogue
It still comes back to the story. In the end, you put that story into the user’s hands. What is the story they are telling? Is it a blog post about their day, or a photo of where they are at that moment, or their plan for their garden this season? Everywhere we travel on the web, we leave a story. A good application assists in this process, as well as protecting it to return to again.
So when you get lost in the complications of the code, remember to surface and check you are still on track. Is what you are doing helping you write the story you want to tell? And if you need a moment of zen, the song that inspired the title of this blog is ‘All Boundaries Are Conventions” from the Cloud Atlas soundtrack.
Top comments (0)