As of Jan 2021, I’ve been working in product space for over eight years. During that time, I’ve experimented a lot with design tools and processes.
Check my portfolio site to learn more about my path (not optimised for mobile use yet, working on it ⛏️).
Within this process there is an important Design Thinking path I like to communicate early to the team and follow quite strictly. The path is divided into two major milestones “Getting the right ideas” and “Getting the ideas right”. Each has few crucial steps that borrow from Design for Divergence and Convergence framework, as well as from Lean Startup process. …
First-principles are the building blocks of knowledge and basic assumptions that cannot be deduced from any other proposition or assumption.
I wrote this post to summarise my thoughts after transitioning from UX design to design engineering. These principles are the result of over ten years of journey through the complexities of development with a non-technical mental model and a curious mind.
This principle is a result of the research I’ve done on state machines for Views programming language. As part of Views, we’ve implemented an experimental state management pattern that was based on this binary fundamental fact that two components can be displayed together or separately on the screen, and there is no other way to arrange what’s going on in a given view. …
03 August 2020
It’s 10:34am Monday morning. I git pull the project like a badass dev would and yarn upgrade the programmatic hell out of it.
A stingy question runs through my half-awaken brain — am I still a designer?
Don’t know. Don’t care — the brain outputs instantly.
I press play, the app launches, and off it starts, yet another magical design-in-production day.
I replace the icon, fix the margin on the menu, add selected state to the tab button, tweak the animation curve when submenu opens, wait…, the animation is too long. I change the duration to 200 milliseconds. …
Let’s get it out of the way; software engineering is a complicated endeavour.
There are several of complex disciplines between front-end and back-end: DevOps, Services, Databases, and APIs, to name the most common ones.
No/low-code platforms, like Bubble, Webflow, or Honeycode, don’t offer enough flexibility, scalability, and dependability for enterprise-level solutions despite efforts to simplify the engineering process.
We’ve tried multiple delivery frameworks with minimal upside. Reinventing processes brings little to none productivity benefits since the code has to be written by someone regardless if tasks are marked as done in an Agile or a Kanban board.
Hiring rock-star developers has some merit but usually comes at a high price and high risk of losing them to one of the giants, like Facebook or Google. …
It’s a random Wednesday night.
I browse through Google Material guidelines. And this question hits me with a speed of Falcon 9 rocket.
What’s the difference between guidelines, design systems, and conventions?
I start poking…
Guidelines are too loose. Design systems are too strict. Conventions hit it right on the nail because conventions are flexible.— As I’m getting overexcited about my discovery, other comparisons rush to my looney mind!
So, I keep going…
Guidelines define many ways I might want to execute a design. Design systems implement specific guidelines as components. Conventions beat both by a long shot because conventions shape my mindset, not my designs. …
Have you heard of low-code and no-code solutions like Bubble or Honeycode? The goal of no-code tools is to make apps without writing code. You can achieve that goal, but you end-up locked in their platform.
Rapid-code is different.
Imagine a combined flexibility of code with simplicity of Lego blocks powered by sophisticated productivity tools.
We call it rapid-code because it’s quick to learn and quick to change. It’s also the most inexpensive way to extend the capabilities of the solutions you build and test them with real users.
The focus of rapid-code frameworks will be to accelerate specific type of delivery with highly specialised development tools. …
Automation reduces complexity.
Technical progress extends the capabilities.
Quality can be reproduced.
Productivity depends on creativity, not receptiveness.
Picking the right tool for the job creates competitive advantage.
Big data insights shape the business models and product vision.
Configuration is more flexible than customisation.
Up-skilling is exciting.
When it comes to product engineering, we will see new tools with intuitive abstractions enabling non-technical team members to contribute to the final solution. Taking new responsibilities will become the driving force behind the motivation for the most talented professionals.
Most of the manual, mundane, and trivial tasks will be automated. Smart automation will surround us with flexible patterns and goal-driven strategies. No-code, like Bubble or Honeycode, soand heavily templated engines will serve the prototyping purpose taking over the spotlight from Sketch and Illustrator. …
My advice might sound counter-intuitive at first, but looking at the hard data, 90% of startups fail, with a 44% survival rate in the fourth year.
That’s 123,300 closed down startups every day!
72% fails because they can’t find a product-market fit or run out of money to keep going. Turns out the design and delivery of the product is one of the most significant factors in finding product-market fit. Our product decisions include the feature set, visual design, and user experience. Why do we get it so wrong, so often?
In this post, I will take a closer look at the remaining 10% of successful companies that got things right and are known for unconventional thinking and execution. …