/ 2 MIN READ
Using OpenPencil on a real project
The useful test of a design tool comes when the screens need to change.
A design tool is easy to like while making the first screen. The more useful test comes later: change a shared control, switch the theme, and see what happens to everything around it.
That was the interesting part of using OpenPencil for Coffee Diary. The design needed to follow the app as its screens and product model changed. A good-looking collection of frames was only the starting point.
One pass used fixed colours and duplicated controls. It looked plausible, but it missed what I wanted from the file. Light and dark needed to be actual theme modes. Buttons and fields needed to be instances of shared components. Otherwise, the next change would mean another round of manual repairs.
The correction was quite concrete: reuse the existing control families, bind colours to variables, and check what happened when modes switched. Component propagation mattered too. If I changed a shared component, did its instances follow?
I also wanted evidence that the saved file contained the intended changes. Reopening it and checking the result was part of the work, rather than treating a successful save as the finish line.
That is the standard I want to judge a design workflow by. Can I return to it after a few weeks and change something without having to remember which copies are special?
For a hobby app, the design file has to earn its upkeep. It becomes useful when it helps me make the next decision, or makes the next change cheaper. A pile of polished screenshots can still leave all that work ahead.