Making your software: Step 1 - A rough specification
/Meet Priya
Priya is a successful interior designer. So successful that she just can’t find time to serve all the projects that come her way. She has a brilliant idea about a software solution that will be able to scale up her operation. A mobile app where many of her customers can actually do their own interior design planning work and then reach out to professionals like her to put the finishing touches to the plan. She knows it will be a great hit, but she has never worked on software project and has no idea where to start.
This series of posts is to help people like Priya. To help her walk the many steps that lead to a successful software launch. This is the story of her journey, with today’s post as the first step she needs to take - create a “rough specification” - a list of features for her software. This list of features will help her explain what she wants her software to do. She will need this for software developers who will build her app and for investors who might fund her.
A name for her product
It’s best to start with a name.
A name of the software project makes life easier, Priya will not constantly need to say “oh that software for helping people do interiors” - she can just use the name. The name doesn’t have to be final, she can stick to a temporary name and use a name that’s different later on. But it’s important to think of a name that gives a feeling of what the software will do. This thinking of a name helps to kick start the thinking for the software’s feature list work too. And, if she can think of a great name that she will use in the real product she can actually buy the domain too. Giving a name and buying a domain actually helps make the project feel more real to her.
After some soul searching Priya decides to name her software “Designly” but decides to buy the domain later as the exact domains were not available (this would be true for most names you can think of - selecting the domain name will take some imagination!)
The user goals
The next thing Priya has to do is list out the goals of the Designly: what will her users achieve when they use Designly. This list is usually called the “user goals”. By listing the user goals out first and keeping them in mind when she thinks about features she is ensuring that she makes Designly useful for her users. Here are some example user goals for Designly:
Users will be able to design their interiors without getting expensive professional help.
Users will be able to quickly try out variations of their designs and colors.
Users will be able to find great interior designers close to them if they need experts.
It may take a few days of thinking to come up with the user goals list. It’s best to give it the time, to think all the goals through, as some goals are not quite obvious, yet after writing out some of the goals they may come out as obvious goals. Here’s one that may make it in Priya’s list which might not be too obvious at the beginning:
4. Users will be able show their designs to friends and family and ask for opinions.
After all, a great value for a software like the one she is planning is that people can try out designs and check how others feel about the design - just as we do in real life for other things.
The user stories
Now that she has the goals listed out she has to come up with a list of how the user achieves those goals. This is usually called user stories in the software world. If she lists them out in a nice easy spreadsheet her software developers would love that. This is what their product analysts have to do anyway and she is just fast forwarding the whole process with her list and also saving a bunch of money.
Here’s a way most software developers like to write these user stories. It all comes from the Agile principles of software development, and it’s worth reading up about this a bit. This agile way of making software is the best for a startup project like Priya’s. So here’s how Priya needs to write the user stories, she should structure each of the stores in the formation of:
"As a ………………. I ………………. , so that ………………. ."
Here’s an example from her product:
"As a home owner, I want to easily try out different colors in my room’s design so that I can see what combination works best for my room."
Since there’s likely to be a whole bunch of these user stories with some of them more important than others it’s good to have them in spreadsheet with the columns laying out the structure and with additional columns that can give other information. We always tell our founders to keep it simple, it’s important to get the thoughts in place rather than worry what’s the right and the wrong way of doing things - since there is no right or wrong. Here’s an example of such a spreadsheet:
A picture or two
With the list of goals and stories Priya would be miles ahead with her software project. She would have something to talk about with software developers or investors. But one extra little effort would magnify her effort by a lot - creating some pictures. You know how it goes - “a picture says a thousand words” (btw, if you ever wondered, that line is originally from Ibsen - morphed into what it is now). In the software world pictures are needed not only because of the thousand words, but also because they might tell the right set of words. Here’s a great picture that explains this (again proving that pictures can explain things so much better! We’ve used this before in a related article that’s worth a read for Priya too: interface between technology and business).
Priya doesn’t have to do anything fancy to make the pictures. Even some hand drawn pictures of how she thinks the software might look like or interact will be a great addition to the rough specification that she is making. But we suggest a great tool that is used by professionals and non-software people around the world: Balsamiq It’s a really easy to use software that let’s you do quick pictures of software interfaces.
With a tool like balsamiq Priya can churn out some concept pictures about the software very quickly. They don’t have to follow any “software UX best practices” or anything, that’s the job of the UI/UX experts. But having these pictures does a double check on the list in the spreadsheet and also helps Priya think through how the goals and stories might actually be in a real piece of software. This understanding of the process of translating words into software interfaces, the difficulties involved and the thought process is invaluable during the actual process of making the software. It would help Priya understand the timelines, estimates and also make her very effective in giving feedback to the designers when they do the actual software interfaces. Here’s an example of how one Priya’s drawing might look like. Even this single picture would help the software developers so much to understand what Priya is thinking of in her software.
That’s it for this step. With the list of goals and stories and with few pictures of the software interfaces Priya is all done for her specification. Now she can find any software developer (the next step in her story) and explain what she needs quickly and ask them to give a price idea. I can tell you that any software developer she goes to will have a happy face when they see her rough specification ready for them!
If you want to use our template for the goals and stories, download it by clicking the button below…. Watch this space for the next one on the series that helps Priya find software developers for Designly.
If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.
