The best way to start a project is to “just start,” right? WRONG!
If you’ve ever turned to motivational videos or pieces for that extra push to start a project, you know the phrase “just start”. Not to say it doesn’t work, no, it actually does, mostly. But there is so much lost in that slogan that it can be just as destructive as it is motivational.
This applies especially in tasks that require a process, a flow, a system for the best outcomes like programming, design, and the like. Jumping right into the thick of it and just starting is not the way to go. The planning phase is just as important, if not more than the execution phase, and I had to be cornered by a recent project to come to this epiphany.
While creating my new web portfolio, I had it all well laid out, planned in my head; I could see the outcome, the result; I could see all who set their eyes on it after I was done in awe. Although I started off well by creating a wire-frame then a high-fidelity design in Figma, I did so only for the homepage. I was supposed to do the same for all the other pages, but boy did my fingers itch for some typing action. Before I knew it, I was in too deep, visualising the design in my head as I implemented it in code.
It took getting stuck on the contact page to remind me that there’s a reason we plan, there’s a reason we have processes we follow, systems in place. This page just wasn’t looking like the one in my head. I spent 3 days on the contact page, trying out all the layouts I could think of, flex, grid, but I just couldn’t reproduce the page from my thoughts.
It took a Figma ad on Instagram to remind me that I was actually going about it all wrong. How timely?
There’s a reason programs like Figma and XD were created. These are design software (yes, not software*s*), creative playgrounds, where you translate the ideas you have in mind on paper. And revise them over and over and over and over again, until you’re satisfied, which is usually never, mostly just settling.
Then with the well-laid-out design, we move to development.
I was doing it all wrong, designing and developing on the fly, using the same tool – VScode; Making one step forward and ten back when I mess up with good code while trying to get rid of the bad. I had gotten away with it for three pages, but it had finally caught up with me.
It took really fighting with my code to remember a process I learned during my internship at Metanoia Web Labs from my mentor.
I woke up the next morning after battling with the contact page for 3 days, prepared a strong cup of lemon tea with honey and sat down at my desk. With pen and paper, I wrote down the process I was going to follow (web design and development):
- Plan (languages, timeline…)
- Wireframing
- Low-fidelity design (Figma)
- High Fidelity design in Figma
- Prototyping – optional (didn’t do it)
- Collecting and organizing assets from designs
- Programming
Looks like a lot, right? Yes, it does, but it isn’t. It’s just a rough outline of what you’ll be doing, one after the other. You don’t even have to do them all. A low-fidelity design might be enough for you to translate into code without a hitch, while others might be required to go all the way, finishing with a prototype.
If you’re only a web developer and not a designer, then by all means start from number seven. You’ll probably receive the design from a designer who will do most of the earlier work, from wire-framing to high-fidelity designs or even rapid prototyping.
So this process/system is not set in stone and can be tweaked extensively to accommodate the nature of your work and the expectations or outcomes of you and your team.
“Phew, finally! The plane has landed…” I get it. But I had to take us all the way for the depth and the need for a process to be seen, felt, appreciated.
I listened to someone and I “just started”, as advised.
I could easily have finished up my web portfolio by the time my previous blog post dropped; Excitement and impatience, however, got the better of me and I paid for it in time – days wasted. I don’t want to go into the rabbit hole of could haves and should haves as I don’t regret this shortcoming. We probably wouldn’t have had this piece if everything had gone smoothly. But we learn every day, hey?
Have fun learning 😁
This is a cross-post from the original in my blog site