I say — Yes to automation! No to complexity! Hell yeah to collaboration and strawberry jam doughnuts!
I will work with an assumption that you
want to ship features that matter and
don’t want to run out of money in the process.
It’s hard to deliver on the above, would you agree?
It’s hard because everything else gets in our way.
We are overloaded with meetings, specifications, refactoring, testing, bugs fixing, and deadline racing.
Specifications are never enough.
From problem solvers, we turn into ticket diggers.
The code we write becomes a tech-debt faster than ever
Here’s a list of the weakest links in our current workflow and some thoughts on what needs to change for us to start delivering at scale.
We build one product, not two, not three. The disconnection between product owners, designers, and engineers is staggering! We need to stop dividing deliverables into specs, mockups, and code.
Change: No process can change that disconnection on its own and without the help of smart tooling. What’s not enough: the fake mockup tools like Framer, InVision, Sketch; the templated app makers like Google App Maker, Appyourself, Trunkable, Zoho, and million others; the tools that integrate designers only on some points of the process, but not entirely, like Supernova, React Studio, PageDraw; the good, old school code editors, like VS Code, Atom, Sublime. We need new tools that make simple things simple, and complex things possible for everyone on the team.
The tech stack locking
Innovation and progress didn’t slow down. Last time it was React, this year it is ReasonML. What’s gonna happen in 2020?
The better the technology gets, the more it enables, the more problems it solves, the harder it is to choose and switch between many languages and frameworks without significant refactoring effort and taking big risk.
I’m a product designer, not an engineer, but I see the struggle against time and resources in my dev team.
Change: We need our architecture to be automation enabled with an easy way to swap languages and frameworks. We need smart compilers to let us try, experiment, and quickly assess the benefits of using other technologies in our stack.
We are stuck in estimations and methodologies. We depend on the process more than on each other. We grow to become experts, and that’s ok, as far as we remain aware that the more we know, the more questions there is to answer. We take our jobs for granted. Let’s be honest we can always find another one. We identify more with a framework rather than a company and its vision. We don’t have time to transfer our knowledge on the job.
Change: Work should be challenging and fun. We should use one common lingo and environment where we can work together, discuss; share ideas, successes, and failures.
The inconsistent code-base and design system
It’s hard to make the code consistent when multiple teams work on different parts of the product. The same challenges apply to the code-base and the design system. Currently, we tend to throw more resources into the mix with dedicated Dev-and-DesignOps teams; and it works, don’t get me wrong, until you start scaling the company. People are the worst to scale.
Change: Not everything can be automated, I hope we all agree with that, like the decision making process. We need well-designed layers of automation to take care of time-consuming and opinion prone processes. I call it “Common Sense Automation”, which stands for flexibility of configuration combined with the simplicity of developer-designer experience.
An example of a simple thing is a change of the a color or label on the button.
An example of a complex thing is a requirement for a custom component, like Google Map.
An example of a configuration is a rule that compiles React code with JSX, or with separate CSS files.
The complexity of running services
I remember times when, as a requirement, we had to have two system admins for every four engineers. Then the Cloud and the Docker came along, and everything changed, became faster, more productive to set up, deploy, and test. Today there is no app without
data, there is no
services, and there is no
Application Programming Interface (API). Unfortunately, we are still forced to design without data because, at the early stage, the services are not yet written.
Change: We need to get to the point when we can develop all parts of the product at the same time. Ideally, we would have the data schema and services derived for us from the specification. 🤔 Again, ideally!
So after all that ☝️, let me pose this question:
What if we could have an automated way for all the stuff we are forced to do manually 😏 ?
Would we use it?
(FYI, We are working on it either way because we need a way to stay sane)
Until now, we’ve managed to automate:
- transformation of SVGs, images, and fonts into React components
- generation of HTML and CSS as React
- creation and management of application flow in React
Here’s a post with more details on the benefits and the workflow we managed to achieve as we keep adding more tools to our delivery process 👇
Will Emergent Design go prime-time someday 🤟💎?
Experimental automation, concept workflows, and state machines in the design space
For release dates and early access to our tools, follow me here or on Twitter.