Integration in Practice
Here at Ness Digital Engineering we take pride in creating great enterprise software. This work involves complexity in strategy, solutioning and execution. As with any complexity, integration of all these different phases is the key.
To do that, we employ our unified method – Connected Ness. What differentiates the Ness process from many others is that it is for us both a framework and a toolkit. A framework helps us identify and explain elements from different disciplines that together constitute the best practice. It helps us onboard staff and clients, standardize our services and deliver consistent quality. As a toolkit, it provides the best instruments available allowing us to appropriate a tool to a problem.
In this series we share some of these elements. While not necessarily new, they help make products a reality.
On pattern libraries
Pattern libraries are in essence digital style guides. Created for code – in code, using HTML, CSS, jQuery libs, etc. This is not merely symbolical – digital specs for the digital age – but primarily practical. Here are the reasons:
Speed
The main need for pattern libraries comes from the deficiencies of traditional spec documentation. For one, traditional specs are relatively long documents that take time to be prepared, time to be read, time to be referenced once developers start developing, and time to be updated once the project evolves beyond the original scope. The outcome is that these documents are rarely actually used, and the rate of usage drops over time as the documents become quickly outdated.
While the difference in the time to create traditional specs and their digital counterparts might not be significant, time to consume is – especially over a long period. In addition, being both categorisable and taggable, each element of the pattern library can be browsed and searched – easily, habitually, intuitively and quickly.
Flexibility
The need for speed is further emphasized by the fact that the development process has radically changed in the past decade or so. Time to release and time to market is shorter, and so are the accompanying development cycles, in pursuit of constant validation, improvement and iteration. Agile has been embraced.
The essence of a spec document is that it is a finished piece, yet the product development reality is one of evolving needs and thus of evolving products. Speed is important, but so is cadence and real-time flexibility. In short, evolutionary product development scenarios require dynamic guides.
Accuracy
Evolving guides certainly contribute to the better quality of execution, consistency and adherence to the agreed design. Moreover, as pattern libraries are coded, so are interactions of design elements. This is very much in contrast with long descriptions of interactions observed in spec documents.
In pattern libraries the functionality is embedded in HTML and therefore intuitive, clear and evidentiary. In addition, the elements together with their behavior do not have to be recreated – often by multiple developers in multiple locations, over and over – but can be lifted from the library, copied and used consistently, as envisioned. This leads to greater accuracy and consistency in the implementation.
Also, behaviors being embedded in design mean that these interaction ideas have been tested. The process itself flags any flaws at the outset, forcing the team responsible for producing them to resolve all issues prior to the actual build stage.
Knowledge
Creating pattern libraries for the initial scope (often MVP, if a new product) should not take much longer to create than a traditional style guide, if at all. However, it does require additional coding skills in the design environment. But this is fully aligned with the product development best practice – design and engineering working in tandem every step of the way. Such effort makes both halves better by improving the overall understanding of the process, product context, needs and dependencies. It also helps create mutual appreciation, builds trust and the team work ethic.
Ultimately, the thorny question of handover disappears, and with it the blame game and the mythical divide between the actually symbiotic disciplines of design and engineering. The process forces the team to take the joint ownership, learn from each other and inevitably create better products.
