Wow! What an experience, thanks for sharing this one!

Thank you all for your amazing answers! I am overwhelmed by the amount and quality of the replies I got from you guys. Good job!

Apart from few interesting tips, most of you still seem to annotate design changes manually. Doesn't matter what tool, but it seems like most of you still go back and document the design changes on your own. Either in some annotation tool or as comments on changed elements - but the problem is still there - you get distracted from the creation process to document things you've already done.

I believe there is an opportunity to complete automate this documenting part. Imagine you upload two versions of the designs - one older and one newer - and the app automatically tells you exactly what changed - down to the layers level.

I tried to visualise it during the weekend: https://cl.ly/rhmK/

Would something like this make your life easier? Or do you consider the problem so small that it's not worthy solving? (inserts forever alone meme).

Thanks for your lengthy comment Thomas! I appreciate the effort!

In the ideal world - yes, this should be the practice. Sadly, in the world or startup hustle, things can and do change very fast.

Especially when your team is working on one particular product, you will never be really "done". You can never see all the cards in the deck at the start, and some things you simply don't learn until some real users get their hands on your product.

It's a classic iterative design mantra - Plan - Prototype - Feedback - Implementation - Evaluation - Plan …

It's simply necessary to keep growing your product, and there will be no perfect research or a masterplan in the beginning that will guarantee you a unicorn in a first go - but rather years of carefully listening to your users and delivering.

That sometimes means changing the design too… in smaller or bigger ways.

Interesting! Thanks for the answer Johan!

I see 2 downsides of this approach and am not sure how you tackle these in your team. As you said, may not work for my purposes, but still would love to hear how you deal with it:

1) The design source of truth is lost - there will be discrepancies between the design in the design file and final product, and it is easy to lose track of what changed for what reason. It harder to work with the design files afterwards if they don't really correspondent with what is in the product.

Or do you have some special ways to keep the design file 1:1 with your codebase?

2) It takes time and focus away from the designer - even when the changes are small, it takes time to communicate changes to the developer in person. It also leads to "designing on the go" syndrome - where designer is trying different styling variants with the developer rather than in his design tool. Which can make this process much more inefficient, considering how each run has to be committed and built out from the command line.

Great comment Paul! Thank you! Nothing beats a good and enthusiastic relationship with your dev team, agreed. Still the documenting part can be greatly automated. As designer, I tried to visualise the solution over this weekend.

https://cl.ly/rhmK/

Do you think a tool like this could help in way or do you think it's not necessary?

I agree. I'd add that in the end product designing isn't painting in Sketch, but creating abstract functionality, defining experience and aesthetics, defining interactions with user. Can't forget incorporating business goals etc.

Achieving all this by applying certain design principles and methods.

Design for me is a way you think about the product. More specific than business manager, more abstract than developer. Therefore if you can share your ideas and propose design solutions without learning new tools, do that.

Yeah, it's a good app :)