I wrote this post more or less a year ago. It met quite positive feedback and became somehow popular. I thought I'll repost it here for you, dev.to community.
In software development, we have a lot of planning and design methods that should help us in creating a vision of a final product. However, as it usually is, they are designed with commercial products created by full and paid teams in mind. What if we are doing our personal project in spare time? We could try to employ those methods too, but they would usually be an overkill and even complicate things more. So, what instead?
I'm afraid the process frequently looks like that:
Oh, I have this BRILLIANT idea for an app with this KILLER FEATURE X. So, I fire up my IDE and start typing. After a few hours of a coding marathon, I already have the X covered and then… I go to sleep. Next day I can no longer find motivation or direction in which I could go. So I stare blankly at the editor window, maybe write some boring features, like authentication or logging. But the thrill is gone, I don’t feel it anymore. As a result, the project lands in the
unfinisheddirectory, never to see the daylight…
You know who else does it? Amateur fiction writers. It’s literally the same: have an idea, open editor, start writing. One chapter, second chapter and… Soon you don’t know where the story should go next or why you created your hero with this particular characteristic. For example, you planned to end the story with an epic battle on top of the highest skyscraper in the city. But in the process it turned out that your hero has an acrophobia and it no longer makes sense. You go back, start to rewrite the first chapter, but it becomes more and more mess. Finally, you give up.
Sounds familiar, right?
So here’s a good news: fiction writers have a lot of tools to avert it and guide their stories to a happy (or not) end. In this post, I try to adopt one I think is particularly useful to personal software project development.
❄️ The Snowflake Method
The Snowflake method was invented by Randy Ingermanson and it is based on the notion of Koch curve, which is a fractal. The idea is to start with something simple (or small) – in Koch curve example it's a simple regular triangle – and add more and more details to have a complex shape.
Each iteration of Koch snowflake corresponds to a step in Snowflake method. Each step adds more details to the previous picture and after each one, you can (and probably should) go back and check if you don’t need to change something on a higher level. Unlike the fractal, which has an infinite number of iteration, Snowflake method for novel design has 10 steps. My adaptation to software design has only 5, but you can add more if you like.
Step 1: One sentence summary
Citing original article by Randy:
Take an hour and write a one-sentence summary of your novel. Something like this: “A rogue physicist travels back in time to kill the apostle Paul.” (This is the summary for my first novel, Transgression.) The sentence will serve you forever as a ten-second selling tool. This is the big picture, the analog of that big starting triangle in the snowflake picture.
In your case, you also create a one-sentence summary. Think of it as of answer to a question “What are you currently working on?” asked by your friend over a beer. It needs to be short, yet telling a lot. You should avoid names because they are not really necessary. Use 10 to 20 words for the best experience.
Examples
- A location-based dating app where you meet people near you ad hoc, without previous setting up a date.
- Framework for writing interactive text adventure games in ClojureScript. – You might note that there is a technology mentioned here. This usually should not happen. But sometimes it actually is a main "selling point" of the project. You may just want to learn ClojureScript. Or maybe there is no such framework in it and you think it is something to fix.
-
Facebook for dogs– too short, not telling anything (what does it mean? it is really for dogs or for their owners? how does Facebook compare?) and uses a name of another service to define yours.
Step 2: Motivation
Take some time to write a longer description. Concentrate on motivation: why do you want to create such an app? Is it for learning purpose? To showcase some technology? You know something similar, but want to do a better version of it? (How would it be better? Why should users switch to your version?) Or maybe you want to solve a particular problem people have?
Original Snowflake article suggests that it should be one paragraph (5 sentences). I think this can be too little in many cases. Don't limit yourself that much. 4 paragraphs are good too.
Step 3: Main features
We start to diverge from original Snowflake method's steps. Instead of describing characters of your novel, concentrate on listing main features of your project. As usually with enumerations, 3–5 is the best number. If you have less, you are probably creating something way too specific – there's nothing wrong with it, but maybe you just don't need a special method to design it.
You can use sub-items for each of your main features to add more details, but don't let it grow too much.
Step 4: Personas
Personas are nothing new in software design, even agile recommends using them. But mostly they are found in UX design. I was never much of a fan of coming up with imaginary people – it's much better if they come from some real requirements survey. But sometimes letting your imagination do the hard work is beneficial.
Each persona should have a valid reason to want to use your project. Write it. And think of them in a way, that their needs are satisfied by main features from the step above. If you come up with 3 personas and none of them used one of the features, maybe it's not "main" at all and you should delete it from the list.
Remember to stay with why, not how. This will be covered in the next step.
If you don't want to invent names and background stories for your personas, you can replace them with simple use cases.
Example
For our dating app from step one, you can create following personas (warning: I'm not good at it, I'm sure you can do it better):
John, 28 years old, is a shy and insecure guy. He want's to meet some girls to date and tried to use "traditional" dating apps like Tinder or OkCupid. However, few times he got "cold feet" and canceled the dates or did not show up. He thinks that it would be better to both set up a date and meet the girl in one of his "moments of courage", not a few days after.
Jeanette, 23 years old, realizes she's a perfectionist. She spends too much time looking or a perfect candidate on dating sites, but she always finds some flaws. Her friend took her on speed-dating once and she really liked that. Forced to talk to people that showed up made her pay less attention to details and she met some really interesting people. She would like a similar experience through her app when she's out in the city.
Alvaro's work consists of many business meetings in the city center. He usually books 2 to 3 hours on each, but they frequently are much shorter. When he has one hour free, why not use this time to meet some people nearby?
What can you learn from this exercise? You are dealing mostly with young people who tried other dating solutions. Yours need to stand out with those unique features they need to get their attention. Also, since they are familiar with other dating interfaces, you should probably create something similar. But on the other hand, you don't need to teach them how it works.
Step 5: User stories
Now it's time to connect your personas to the features even tighter. Describe how they use your project. Maybe you need to add some more details to personas you wrote? For example, if Jeanette was using iPhones her whole life, she expects some UI similarities and would not like if things are organized differently.
But there are more important things to cover here too. For example, how do two people decide on a date? Do they swipe like in Tinder? Send a message? Do they look at each other photos before or maybe they have even less information available, not to create anticipations? Finally, how should the recognize each other when they both are in the same place?
And what happens after? Maybe they should swipe after they talked? If they both swiped "yes", the messaging module is enabled and they can set up another date. Also, what happens if a person does not show up? Should he be reported and other users should be warned?
As you see, there is a lot of scenarios here. This might end up being the longest section of your "snowflake document". But in the same time, it will be the one that would give you most insight.
What next?
These are main 5 steps I think are necessary. But the journey is not necessarily done. You can add more steps. They would probably touch different aspects, not more details. For example:
- Create UI mockups based on user stories from step 5.
- Make a technology survey. Find the best database for your data. Or prettiest UI framework.
- Create an outline of documentation in a way that questions users might have are answered.
Full example
I prepared a full example of snowflake analysis for a project I'm doing for "Get noticed!" contest. It was done "live" and includes footnotes about things I learned about the project during doing it.
Have fun snowflaking!
Top comments (0)