Started as a designer

Back in 2016, i started as Media Designer in a small digital agency 'Loy GmbH' where we focused on small or mid-sized companies handling the online e-commerce business for them.

My task was to create layouts, back in the days in Photoshop, and providing those layouts to the developer.

Not long time later, i discovered that i don't want to stop there at designing, i wanted to know and understand what's happening after the design step.

From design to development, a first step

At first, i only handled HTML and CSS changes, primarily inShopware 5at that time, which usedTwigas template engine.

JavaScriptwas coming slowly into the game, and i took a first Udemy course. (Props to the mastersMaximilian Schwarzmüller,Jonas SchmedtmannandBrad Traversyfor introducing me in the fundamentals and beyond)

It took me several starts until this ecosystem clicked to me. But the more i knew about it, the more i knew: i found something which i really care and be enthusiastic about.

From there on i focused on adapting the design changes into the real, production-ready user interfaces i initially designed.

React, Next.js and TypeScript

Translating an idea from the mind, to paper, to pixel, to code into real-world applications has always been the most motivating thought that drove my mentality to keep on learning.

With that, building large applications in the modern JavaScript ecosystem inevitability leads to the big playersReactandNext.js.

While i also took a close look atVueand enjoyed the elegant and more 'premium' syntax of it, i stuck and got more into React because of its larger community, the wide-spread package options and the job opportunities.

Also, with React i felt more in the real JavaScript environment than with Vue (which can be a pro or a con depending on how you look at it).

TypeScriptcame as last piece to the puzzle which in the retrospective was a wise decision, as most of today's web applications or frameworks require TypeScript as the base.

Of course, there are much more frameworks out there, like:

But in the end, the tech stack is the framework bringing the application to life, not the key factor of the project.

Together with other tools and technologies, they build up the technological system that makes this initial thought a reality.

Making the full circle, connecting with my root dots

Design Engineering. It is per definition described as "Design engineering combines design (appearance) with coding (functionality) to create smooth, easy user experiences." which makes it good for a person having both abilities: to plan, visualize and create on the one hand and to build, perform and function on the other.

This benefit, of having both sides of the front-end spectrum makes it easier and better to design, while also better at coding because the same person knows what the other department is about and the values of it. Also, in the end both departments are needed to create the desired product (the user interface) that should mirror the business goals and its intentions for the people using it.

During the last years working more in the field of coding, i noticed something crucially for me. I miss design. Without a vision while work, simply building user interfaces for the sake of it, feels shallow, almost hollow to me. No soul, no good reason to reach for. It becomes harder for me to enjoy what i am doing.

That's why i am convinced that projects and everything what you do should have a clear reason why, a descriptive meaning what you want to achieve before you do it. This means a vision description, a mission description and a description of the values, the reason why of it. And – sticking to it, investing time into it.

It actually has another benefit: you have a clear path to go on. I'm sure that when the path is clear, so will be the product, with more focus and clear intentions.

In the current industry, this relates most of all to requirements engineering, making it super clear what's to build, why to build and how to build – based on specific requirements. Without this roadmap, products, features, or enhancements are set up to fail before they even begin.

This may sound obvious, but in day to day work this often gets lost quickly, especially in longer-lasting projects and the overall way of work, focusing primarily on "making it work" and "shipping it". Fundamental requirements changing while being in the process is not agile, it is bad planning. With the lack of these definitions, the result will be fuzzy. Therefore, strong management is needed. And people that what to carry the idea and vision from beginning to end.

With all of that said, i am happy to see what is coming next, and what good things we can build for the web and the people using it.

Source:Design Engineering