What is Spaghetti Designing
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.
TL;DR Pros
- It’s obviously quick which is a huuuge thing
- It’s quite cheap
- With experienced design efforts, it’s not bad.
- You automatically focus on the features that define your product and eliminate unnecessary ones.
TL;DR Cons
- It generates a lot of design debt which is expensive to fix in the future
- You still stick to a single piece of software
- You lose consistency very quickly
- Not everyone on your team may be satisfied with this approach, as they may expect to have solid data to use as a foundation for the mockups
- It may not be suitable for all types of projects, particularly those with strict requirements or regulations.
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.
Mkay, but let’s first define business needs
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:
- A pre-product clickable prototype for investors and pitch decks
- Developing the MVP to prove the concept
- Low and no-budget products with urgent needs
How can you be user-centric without understanding your user?
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 gut.
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:
- It is difficult to conduct thorough research when the owner requests a quick turnaround. Speed and quality are often at odds with each other. If time and budget allow, it is best to conduct in-depth research. If not, consider minimizing the research or even sacrificing it altogether.
- I have worked at a company that claimed to stick to processes and have frameworks for product design, but never really followed them. Their work was purely based on hypotheses. I decided not to continue working at that company because of this. However, it is worth mentioning that they succeeded and their product brought in a lot of revenue.
- Let’s be fair, research is important, but not every startup can afford it. Therefore, I think it’s okay to apply some “spaghetti principles” for MVP work.
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.
But do I still need to plan what I design?
Most certainly. Actually, planning is the only thing that costs 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 is a list of things you’ll need to consider as a bare minimum when planning:
- Decide on goals and design success criteria based on them. Is it a clickable prototype? Or maybe a fully developed MVP?
- What are the “must” and “no go” features? It’s better to avoid “nice to have” features listed as you can lose the focus)
- Define the basic user tasks. For example, “As a user, I can filter displayed items so that I can identify broken items.”
- List the frames per feature. E.g. Login/Sign up flow will need both Login and Sign up forms with SSO options that will be merged into a single screen with tabs selector to switch between, Restore password and Confirm email.
- Estimate your timeline and resources. Make sure you have enough time and resources to complete the project with the desired quality. Estimate how long it will take to design each feature or page and make sure you have enough designer and developer resources to complete the work in a timely manner.
What if I have no brand identity to base my mockups on?
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 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.
How about a design system and components?
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 design work. You’ll be surprised how quickly 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.
So while you may not know what components you’ll ultimately need, it’s important to have some fundamentals in place.