In many of the teams that I have joined in the past, I have found a situation similar to the following — they seem to work and deliver things quickly, but without following a reflected approach to their interface design process; there are almost no shared libraries nor practices; and finally, the design documentation seems to serve a very short-lived purpose, being as useful as necessary enough to keep shipping things out of the door.
For a newly hired designer, such a situation does not look very promising. The implications of this exponentially grow as more and more people become part of the team, even if its size remains quite small. (From my experience, in a team of only three designers you’ll already start feeling the urge of setting up some common practices on how to work together.)
As a consequence, a lot of the initial onboarding time that should be spent on learning how to navigate through the company is spent instead on finding files and previous design versions, all of this in an attempt to figure out how the product works. Having these at hand also helps recognize past decisions, as if they were a log to keep track of the design’s evolution, leading to a better understanding of what the current version works the way it actually does.
Before we continue, I think it’s important to understand why working in an apparently disorganized way seems to be the norm — and why maybe this even seems to be somewhat really working in so many teams.
One of those reasons could be due to pressure from managers to deliver more, and to deliver quickly. We think that we’ll go faster if we leave layers, groups, and components unnamed. We don’t stop to organize them in a way so that they will be easy to update in the future. Spending time refining our design workflow to something that could be useful beyond this specific point in time seems unnecessary (and it even seems to slow us down) when there are other, more urgent things to do instead.
To get latest updates on courses and news regarding education.