DEV Community

Cover image for How to Design Great Software Products in Small Startups
Ilona Codes for Foundsiders

Posted on • Originally published at

How to Design Great Software Products in Small Startups

If you are aware of the values of carrying out the Product Design Process, then you are halfway through the success!

And when you are starting out, you tend to change processes every day, until the team figures out which processes are the most efficient for them to deliver faster.

"If you want to have time for everything: raising children, loving, working, playing sports, relaxing, you need more time. Only those who work faster and better will flourish." β€” Carl Sewell, Customers for Life.

You can build a good digital product by working in a small team in the beginning. Just think about the most strong brands with their successful digital products: I am sure, all of them that came to your mind started small in the past.

In fact, the product design process is one of those questions that is done differently everywhere.

Typically founders take responsibility when it comes to this. For example, at Foundsiders, I am in charge of developing the design concept, and other co-founder implements it into the working application for the most part.

Founders who are bootstrapping their products clearly understand the advantage of working on a small team: the smaller the team, the less formal the process is.

For design products at small startups, it usually means that the team can re-design pages/flows on the fly in their code, view that code in browser debugger/inspector, and iterate again.

Moreover, much of the design will probably be on paper or whiteboard. How does it work:

  1. Someone has an idea πŸ’‘

  2. Quick discussion πŸ’¬ on the feasibility of the idea

  3. Do a quick research πŸ‘©β€πŸ”¬ to understand: why users will need this idea and which user's problem will it solve. This will lead to a rough blueprint of the feature in the next step.

  4. Sketching out and wireframing πŸ— the idea into the app screen. It's necessary to refine and iterate on the vision from the wireframe, so you can use Balsamiq to do that.

  5. Design mode 🎨 Going through each wireframe and laying design mockups on top with the Sketch app. However, you can use whatever app that works for you. It's just a tool.

  6. Export ready mockups to Zeplin. Then as the team, we can navigate around it, perform design reviews πŸ“ and agree on what is going to be implemented.

  7. Build the idea into the product locally. Frankly building a feature into a static frontend πŸ‘©β€πŸ’» version of the product.

  8. Validation and iteration within the team πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

  9. Validation outside of the team with the potential user πŸ‘€ (Don't skip this step if at all possible).

  10. Again iterate to decide βš–οΈ whether to develop the idea implementation further, change direction, or drop the idea altogether.

  11. Develop the end-version of the idea into production and deploy it βœ…

  12. Gain learnings from data collection πŸ“Š (review engagement and conversions).

Here is a brief explanation of the feature development cycle for the digital product:

Feature development cycle for the digital product

Since you work at a small startup, you have a few resources. And it's for the better. Because everything works best when all hands are helping out and always have what to do.

For instance, the non-technical co-founders can be validating the usability running it by potential users or coming up with better ideas, do customer and market research, and so on. The tech people are doing everything the non-tech people are in addition to building out the tech according to their professional expertise.

Now I am wondering, how does look the design process for the product you are working on? Please share it shortly in the comments below πŸ‘‡

Top comments (4)

dividedbynil profile image
Kane Ong • Edited

After joining a few startups and being in their product design cycle, here is the common mistakes I found:

  1. Development starts before market research.

    • I have seen many founders prioritize action and deliverables, but their assumptions are not lining up with the market. Most of the effort can be saved by knowing the market better.
  2. Getting pilot users at the later stage of development.

    • Similar reason as above, pilot users can tell you a lot of their expectations, which can save you tons of development effort and aligning your assumption. Their opinions are more valuable than full-fledged features of your product.
  3. Having a strong vision by neglecting advice.

    • I have seen founders talking with their background and success story, but falling into the pitfalls that I advised in the first week.
    • A profound voice will turn mute eventually because an employee may not spend too much time arguing with founders. Just remember that your employees have better options if things go sour, but your business may not be.
  4. Process-oriented but not goal-oriented, or the opposite.

stereoplegic profile image
Mike Bybee • Edited

The startups I'm working with are typically too small for three different design tools just to plan an app, and frankly I think larger ones would to well not to sink so much time, resources, and process in them either. If I'm spending that money, I'd much rather allocate it to more developers and infra to get the real thing out there faster, than designers and design tools.

And personally I'd rather hand draw wireframes. Sketchize's free templates are great for this, but plain graph paper works too. I read about how Zurb (makers of Foundation) do this with Sharpie to minimize constant fiddling with styles and sizes and just crank out the basic idea (I get that Balsamiq is designed with that in mind, but there's still a lot to waste time fiddling with), and that's what I've stuck with ever since. Balsamiq feels like overkill for something so simple. Draw, scan or snap a pic with your phone, and share.

From there, I typically take it straight into laying out elements and basic routing in code (React Native/React Native Web), which can be pushed into Sketch or Figma via react-native-sketch or react-native-figma, respectively, if needed (usually not). Instead of then putting these into a separate live prototyping tool like Zeplin, they can test out the actual code on a staging site, Expo app, etc., or screens can be prototyped in Sketch/Figma's own prototyping tools.

Tip: You can set up an api-only Trello account and integrate a feedback form in the app itself early on which creates various cards on the project board from said feedback. Map a "feedback type" field to various Trello labels (bug, feature request, user interface, etc.), and you have an immediate feedback loop to fill your product backlog while building it out, without "how do I leave a note about ___?" questions related to a prototyping product interface you didn't design.

bernardbaker profile image
Bernard Baker

Kick started my startup. And the product design process is always pretty simple. I have an idea and prototype it if there is a viable customer use case, or if it will improve business operations by ways of saving time, people effort or money.

Any advice?

mzahraei profile image

I don't heard anything like that, amateur version.