GLUE:
Each project has its own character, but when I get to do it my way, there are a few essentials. To me, these are sine qua non — fundamental conditions for good work. Conversations with others have shown me that this is not universally assumed.
Here is a look behind the scenes at how I approach my process.
00 Anticipate iterations
Universal truth
Projects evolve. Feedback reshapes decisions, corporate identities unexpectedly go through major shifts, new people join the team. I cannot plan for everything, but I can design with change in mind and prepare for the inevitable bumps along the way.
The more I discuss in the beginning, the deeper I dig regarding core elements, the easier it wil be to play around with the design.
What I do
Before creating the first design file, I like to start with sketching either pen on paper or in Excalidraw (especially when working remote or in a team). It feels more temporary which makes it easier to let things go, experiment with the design, brainstorm, explore.
01
Excalidraw wireframe example
02
My notebook full of all my designs
01 SEt up for success
Working as a software developer taught me many a thing, but one practice I cannot live without is consistent naming conventions. They keep files orderly, streamline the search, ease collaboration.
If a team does not yet have a shared system, I will start making the case for one from day one.
03
File names
04
*This* portfolio’s structure
02 update-proof the file
I build a design system even for the smallest projects. Scaling up and adapting to work within a complex systems is hence not much of an issue.
Design tokens
05
Working with local styles for small projects
06
Using plugins to generate docs
Components
07
Nested naming...
06
... makes it easy to manage the assets...
07
... and export them for developers
08
Nested instances
09
The more complex a design becomes, the more essential variables are
03
File names
04
*This* portfolio’s file structure
03 forget-me-not
Document as if your life depends on it. Clear documentation reduces ambiguity, prevents avoidable mistakes. It shortens alignment cycles and limits unnecessary status meetings.
10
Some changes might not always be spotted
Hope this gave you a glimpse. Care to see how these principles play out in other projects?
GLUE:
Each project has its own character, but when I get to do it my way, there are a few essentials. To me, these are sine qua non — fundamental conditions for good work. Conversations with others have shown me that this is not universally assumed.Here is a look behind the scenes at how I approach my process.
00
Anticipate iterations
Universal truth
Projects evolve. Feedback reshapes decisions, corporate identities unexpectedly go through major shifts, new people join the team. I cannot plan for everything, but I can design with change in mind and prepare for the inevitable bumps along the way.
The more I discuss in the beginning, the deeper I dig regarding core elements, the easier it wil be to play around with the design.
What I do
Before creating the first design file, I like to start with sketching either pen on paper or in Excalidraw (especially when working remote or in a team). It feels more temporary which makes it easier to let things go, experiment with the design, brainstorm, explore.
01
Excalidraw wireframe example
02
My notebook full of all my designs
01
SEt up for success
Working as a software developer taught me many a thing, but one practice I cannot live without is consistent naming conventions. They keep files orderly, streamline the search, ease collaboration.
If a team does not yet have a shared system, I will start making the case for one from day one.
03
File names
04
*This* portfolio’s structure
02
update-proof the file
I build a design system even for the smallest projects. Scaling up and adapting to work within a complex systems is hence not much of an issue.
Design tokens
05
Working with local styles for small projects
06
Using plugins to generate docs
Components
07
Nested naming...
06
... makes it easy to manage the assets...
07
... and export them for developers
08
Nested instances
09
The more complex a design becomes, the more essential variables are
03
File names
04
*This* portfolio’s file structure
03
forget-me-not
Document as if your life depends on it. Clear documentation reduces ambiguity, prevents avoidable mistakes. It shortens alignment cycles and limits unnecessary status meetings.
10
Some changes might not always be spotted
Hope this gave you a glimpse. Care to see how these principles play out in other projects?
GLUE :
Each project has its own character, but when I get to do it my way, there are a few essentials. To me, these are sine qua non — fundamental conditions for good work. Conversations with others have shown me that this is not universally assumed.
Here is a look behind the scenes at how I approach my process.
00
Anticipate iterations
Universal truth
Projects evolve. Feedback reshapes decisions, corporate identities unexpectedly go through major shifts, new people join the team. I cannot plan for everything, but I can design with change in mind and prepare for the inevitable bumps along the way.
The more I discuss in the beginning, the deeper I dig regarding core elements, the easier it wil be to play around with the design.
What I do
Before creating the first design file, I like to start with sketching either pen on paper or in Excalidraw (especially when working remote or in a team). It feels more temporary which makes it easier to let things go, experiment with the design, brainstorm, explore.
01
Excalidraw wireframe example
02
My notebook full of all my designs
01
SEt up for success
Working as a software developer taught me many a thing, but one practice I cannot live without is consistent naming conventions. They keep files orderly, streamline the search, ease collaboration.
If a team does not yet have a shared system, I will start making the case for one from day one.
03
File names
04
*This* portfolio’s structure
02
update-proof the file
I build a design system even for the smallest projects. Scaling up and adapting to work within a complex systems is hence not much of an issue.
Design tokens
05
Working with local styles for small projects
06
Using plugins to generate docs
Components
07
Nested naming...
06
... makes it easy to manage the assets...
07
... and export them for developers
08
Nested instances
09
The more complex a design becomes, the more essential variables are
03
File names
04
*This* portfolio’s file structure
03
forget-me-not
Document as if your life depends on it. Clear documentation reduces ambiguity, prevents avoidable mistakes. It shortens alignment cycles and limits unnecessary status meetings.
10
Some changes might not always be spotted
Hope this gave you a glimpse. Care to see how these principles play out in other projects?
GLUE :
Each project has its own character, but when I get to do it my way, there are a few essentials. To me, these are sine qua non — fundamental conditions for good work. Conversations with others have shown me that this is not universally assumed.
Here is a look behind the scenes at how I approach my process.
00
Anticipate iterations
Universal truth
Projects evolve. Feedback reshapes decisions, corporate identities unexpectedly go through major shifts, new people join the team. I cannot plan for everything, but I can design with change in mind and prepare for the inevitable bumps along the way.
The more I discuss in the beginning, the deeper I dig regarding core elements, the easier it wil be to play around with the design.
What I do
Before creating the first design file, I like to start with sketching either pen on paper or in Excalidraw (especially when working remote or in a team). It feels more temporary which makes it easier to let things go, experiment with the design, brainstorm, explore.
01
Excalidraw wireframe example
02
My notebook full of all my designs
01
SEt up for success
Working as a software developer taught me many a thing, but one practice I cannot live without is consistent naming conventions. They keep files orderly, streamline the search, ease collaboration.
If a team does not yet have a shared system, I will start making the case for one from day one.
03
File names
04
*This* portfolio’s structure
02
update-proof the file
I build a design system even for the smallest projects. Scaling up and adapting to work within a complex systems is hence not much of an issue.
Design tokens
05
Working with local styles for small projects
06
Using plugins to generate docs
Components
07
Nested naming...
06
... makes it easy to manage the assets...
07
... and export them for developers
08
Nested instances
09
The more complex a design becomes, the more essential variables are
03
File names
04
*This* portfolio’s file structure
03
forget-me-not
Document as if your life depends on it. Clear documentation reduces ambiguity, prevents avoidable mistakes. It shortens alignment cycles and limits unnecessary status meetings.
10
Some changes might not always be spotted
Hope this gave you a glimpse. Care to see how these principles play out in other projects?