Blog8

As a consumer similar to everyone else, have you tried asking yourself why most products today have somehow seemed
to get worse with age?

I think that the answer lies in most businesses or companies not adhering to a solid underlying design system that unifies
and serves as a guide to all aspects of the experience. From the moment on the conceptual building of the product to the
details of the UI, then up to how things are named; one must gain a good foundation on how to go about through every
step or level of the process.

In developing a system for a specific product, the key is to represent your core principles at various stages - using the term

a Full Stack System that is comprised of the following:

1. A shared product conceptual model

Like the diagram you’d illustrate on a whiteboard to explain how your product works at every system level.

2. A language shared

By everybody on your team to refer to your objects. Bear in mind, that words matter immensely. In the event that designers,
engineers, and support people use exactly the same word to describe an item, a lot of confusion gets eliminated.

3. Shared assets on design

Like the diagram you’d illustrate on a whiteboard to explain how your product works at every system level.

4. Shared components on codes

That allow developers to build these components and their variations, typically containing a single line of code - must have
a 1:1 mapping of the objects in the sketch as in the codebase.

4. Shared components on codes
1. A shared product conceptual model

Substantially, it’s imperative that all these levels have a unifying thread. Such as communication in Streamline – one of our
core objects – is a very specific thing whether it’s being sketched, designed, described or coded. If we want to change
something on that object, we can consistently change it across all levels since teams are locked in and ambiguity disappears.
In this way, the sum of the system becomes much greater than the parts.

We must also understand first that in all types of complex systems, clarity comes from understanding first the whole as a
series of modules, then zooming in to think of each module individually.

And according to John Gall’s eponymous law: “A complex system that works is invariably found to have evolved from a
simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never
works and cannot be made to work. You have to start over, beginning with a working simple system”.

We can always have the ability to design complex systems, but in order to do so, you must first sketch the outline. Only then
can you start filling in the details. Likewise, to evolve and improve a complex system you must keep the overall system in
mind at all times. We already know the alternatives don’t work: taking on new ideas gradually, resisting the need to grow
the product, allowing many competing approaches to co-exist.

We must use a technique for holding both the micro and the macro in our tiny human skulls at the same time. Christopher
Alexander, who wrote “Designing with Systems”, said that: “Nowadays, the process of growth and development almost
never seems to manage to create this subtle balance between the importance of the individual parts, and the coherence of
the environment as a whole. One or the other always dominates”.

In getting your product to grow, there must be a constant balancing of approaches and design at every level so as to avoid
letting one element dominate over the other.

Don't forget to drop your comments or questions below and visit as on our site (Streamline) in order to know how each level
of our full stack systems works.