Spaghetti designing is a more flexible and adaptable approach to designing that involves creating a design that is free-flowing and can be easily changed or modified as needed. Instead of having a strict plan or blueprint, spaghetti designing allows designers to respond to feedback from users, make adjustments based on new requirements, and generally be more responsive to changes. The primary goal of using the Spaghetti Design methodology is to speed up your minimum viable product (MVP) development as much as possible.
Before we dive into the details, it’s important to keep in mind that there are no bad ideas, only ideas that do not work under certain conditions. I still strongly recommend going through all the product design steps, including research, user stories, flows, and more. Although it may be hard to believe, some really good products have been designed without any research. At least, that’s what my design friends say.
I have heard many times that some early-stage startups struggle to raise funding without any visuals to show off which is not a wonder. And I’m not referring to onboarding first users with a product that has not yet been any implemented. Getting mockups done in a short period of time can dramatically change the situation.
Then some brainiacs can say that you should learn about your audience, conduct research, plan infrastructure, and only then design the very first version. While there is some truth to this, let’s consider the needs of the business and what would benefit it more: A. A proper product design journey that takes 2 months or B. First mockups done within a week?
Yeah 🙃
You need to decide what the business needs for the MVP. The ideal goals should be:
Hold on a second, you still have self-awareness and can use your intuition to base your ideas on. It may not be the best advice, but it’s better than nothing, right? A better piece of advice would be to get rid of your imposter syndrome and start trusting your guts.
And that’s where things become really interesting. I asked some friends of mine who have decent experience in product and UX design, and here’s what they said:
To prove your concept, you can benchmark what both your direct and indirect competitors are doing.
But please don’t go to Dribbble looking for inspiration as 95% of the product shots are just concepts that have no connection to the reality.
Most certainly. Actually, planning is the only thing that cost you nothing but boost your productivity dramatically. Make sure you’ve listed the features and product pages you’re going to design
In a nutshell, here are a list of things you’ll need to consider as a bare minimum when planning:
If you have no brand identity to base your mockups on, you can create a temporary brand identity that aligns with the overall look and feel you wish to achieve. This temporary brand identity can be used solely for the purpose of creating the mockups and can be updated later when the final brand identity is ready.
It won’t be a problem for an experienced designer to come up with some initial branding ideas. However, keep in mind that redesigning the mockups according to the established brand identity will come at a cost.
I know many people who did a great job and had some good-looking mockups within a week, despite having no branding in place. These individuals designed products that generate a lot of revenue today.
Solve problems as they arise. It can be stressful to not have enough time to establish proper design system fundamentals. However, it’s still acceptable to fill a design system with components while doing spaghetti designing work. You’ll be surprised how quick it is doing both things at the same time.
Before creating mockups for the Multiply web app, I established the fundamental elements of a design system, including buttons, styles, checkboxes, and inputs. Interestingly enough, we never ended up needing those inputs at all. Instead, we implemented a block system where a typical text block could be used anywhere, even as an input component. This allowed us to easily substitute it for all dialogues where inputs were expected.