From sketch to software: 10 steps to build major app features
Have you ever wondered how an app gets built? How it makes the leap from being an idea in someone’s head into a working piece of software out in the wild? Of course, there’s no all-encompassing answer, since different companies work in different ways, and their processes evolve over time. That said, here’s the rundown of how we’ve been building major features at Axial, a mid-stage startup, based on my experience as a Product Manager here for the better part of a year:
Step 1. The “why” — target your goal.
This requires a careful assessment of the business’s strategic opportunities and risks, an understanding of your customers’ true goals, and a commitment to identifying and the most pressing problems which could be solved with technical solutions.
Step 2. Challenge and inform your own thinking.
These ‘solutions’ will come with risks and questions. You’ll need to think through them and ask yourself if you’ll need to run a lightweight experiment or perhaps build a prototype (i.e., do user research) to learn and address those risks and increase your confidence in the path forward. Ideas should be de-risked to earn priority on the roadmap. If something seems too risky, or would require too much effort to pull off, it should be adjusted or even abandoned before spending any more time on it.
Step 3. Collaborative design.
At Axial, once we’ve decided to tackle an item on the roadmap, we hold “Design Studios” to surface creative ideas about the topic at hand. People across the entire company are invited to participate, because good ideas can come from anywhere. At these sessions, everyone gets a large piece of paper, upon which we quickly sketch our visions of the topic at hand. We then present our sketches and vote on the best ideas. These papers are then collected by designers for creative fodder in the next stage of development.
Step 4. Synthesize and share.
This stage is all about organizing our ideas in a way that is conducive to generating feedback and making rapid adjustments. Whether that means working on a whiteboard or a low fidelity mockup using Google sheets is up to you — the important thing is to put the best ideas together and start molding them into a state that can hold water. Again, this is a time to pull in software engineers, customer support, marketing, sales, data, and any other internal stakeholders so they can react and contribute while the concepts are still malleable.
Step 5. Prototype and test.
As the design becomes more developed, it can be time to transition to a higher-fidelity prototype to validate thinking and surface new issues (even the most brilliant product and design team can only anticipate so much of their users’ behaviors and goals). The type of prototype you build, though, depends on what you are trying to test. Sometimes, paper prototypes can do the trick just fine. At Axial, when we’re testing more complex usability issues, we use Sketch and InVision to simulate a product experience, with screens that a user can click around and interact with. Even early versions of these prototypes can be put in front of customers as tools for learning. Each feedback session produces learnings to use as we develop and improve the app.
Step 6. Write stories.
A story is a tool to create shared understanding, primarily so they know exactly what the expected behavior is for the features they’ll be coding, and why. Stories go something like this: “As a user, I can click ‘Preview Teaser’ to trigger a full-screen takeover so I can see how my deal information will appear to recipients”. Anything that gets built at Axial is first written in story form.
Step 7. De-scope.
Every additional feature — every additional bit of complexity — takes time to build, and engineering time is expensive, especially for a startup. We look at the stories we’ve written, and ask ourselves how much we could get away with cutting: what is the truly minimum version of this product we could deliver to customers and still provide value? The rest of the stories go onto a wishlist that can come as “fast-follows”, through a weekly cadence of iterative improvements.
Step 8. Build.
With the stories written, they can be reviewed with the engineers and prioritized in the form of a backlog. The engineers then work their way through these stories, with stages of testing along the way to catch any bugs before we allow the work to go live.
Step 9. Roll it out and follow up.
The most rewarding part of the process is seeing customers react to the work. If you were truly ruthless in your de-scoping, then you’ll probably be nervous about how much is missing from this first release. I imagine the feeling is similar that of sending your kid off to Kindergarten for the first time: the work may not be polished, but it’s time to give up control and let it out the door. The next few weeks (or months) will be all the more rewarding as your team adds those missing features in, basing their priority on any metrics and customer feedback you can gather after the release. It might make sense to roll out the feature in batches, so that you have a chance to make the most valuable improvements before you expose it to successively larger groups of customers. It takes discipline to stay focused and actually produce those iterations, but it is through releasing, measuring, and iterating, that a product achieves real greatness. Saving the “nice-to-haves” for after the release also unlocks an added layer of efficiency: some of those things which may have seemed so important at the outset may end up being totally unnecessary at the end of the day.
“Step 10”. What’s next?
I didn’t mention this, but all this time, it’s important to have been thinking ahead and running this process for things to come. There are still plenty of problems remaining on the roadmap. The only way to be efficient is to work in parallel: iterating on the old, while de-risking, designing, and building the new.
