Today I read an interesting article by Viljami Salminen titled On Design Tools and Processes. In the article Viljami gives you a flash tour trough the history of graphic design.
His point was that, many of the tools we are using today still use this paradigm of the printed page. Even in tools like Sketch, we are still confronted with what size to set our artboards (the printed page) to.
It is no wonder that when we come to translate such designs; it is hard to get away from this idea of pages.
Even in our world of many devices with a variety of shapes and input methods we still think about the printed page as being 1-to-1 with say a mobile screen. In his article he explains that even if we have a mobile screen, we have an infinite amount of real estate. You just have to swipe to see it.
As we move away (hopefully) from this idea of the printed page–even while we are in this transition–it is critical to think in terms of tools and processes. Ones that foster communication across the dividing lines of specialized teams. Once only the realm of the designer, or perhaps on the realm of the developer, he suggests that using the tools of Design Systems Engineering (style guides, pattern libraries, modular code based design systems AKA front-end code, etc.) should now get many more people involved.
Here is a direct quote from his article:
source: https://viljamis.com/2017/design-tools-processe
The goal of this is to foster conversation and collaboration amongst teams. Tools such as a coded / living styleguide and front-end code (live examples of templates and patterns in the wild) go a long way towards having a common language across teams. You put more effort into the naming of components because you know these names will be used across your organization.
In the article Viljami continues to suggest how we might overcome some of the limitations of our current page driven design tools.
Here is another direct quote from the article: 
source: https://viljamis.com/2017/design-tools-processes
I have written before about the benefits of solving UX issues in the browser. I also wrote yesterday about the cyclical nature of design systems and gave some strategies on how to navigate from design to development and then back the other way.
The important question here is at which point is it more productive (in terms of team communication) to produce design artifacts in a tool like Sketch verses creating a coded prototype.
I would say the answer depends. It also is possible to use both. The ideal situation is when you use the right tool for the job, and then let one experiment inform the other.
Tools like Sketch and Photoshop will be a better tool for building up elements of a strong visual brand. Making color choices, cropping and placement of images, and even typography are going to much easier to change in this environment.
Creating a coded prototype (or Scaffolding) is a great way to build out entire layouts with pre-built components. Frameworks like ZURB Foundation make this process much faster and consistent, but you could do the same with writing code from scratch. The other thing that the Scaffolding access at is interactivity.
There are methods and tools to export wireframes and mocks from graphic apps so you can create the simulation of interactivity, but often these fall short.
In HTML it is trivial to link to another page. When you make updates, you don’t have to redo the whole lot. (With many other tools like InVision, this can be a bit of a chore)
However, there is a point where you get diminishing results from a specific tool.
I am not in the belief (yet) that code is the end all be all answer to everything. There are things that will simply be faster with a better tool. Sometimes it is quicker to just pick up a Sharpie and a pad of paper.
The key takeaway is you should start to recognize where those gaps exist and ask yourself some questions:
**Is this the best way?
Is this the best tool for the job?
Am I communicating this idea as clearly as I can with the least amount of effort?**
This grey area of working between tools and disciplines is the realm of the Design Systems Engineer. Someone who not only can pick the right tool for the job, but also tell you why they chose that tool.
