Which Shade of Gray Should I Use For Disabled States?
Which Shade of Gray Should I Use For Disabled States?
Which Shade of Gray Should I Use For Disabled States?
September 15, 2017
September 15, 2017
September 15, 2017
Design systems have done much in terms of advocating for and advancing collective thought towards the notion of component-based design and development strategy. By documenting patterns and discussing the application and extension of those patterns, the design system has established a kind of figure-ground relationship between the things that are and are not a part of that system. What is, is recorded, and what is recorded describes what their is.
But a design system is not a library of sketch symbols neatly arranged on an infinite canvas, nor is it a folder of components, or set of pre-made templates. It’s not the dos or the don’ts. And while design systems that are generated from code tend to be easier to maintain and describe a more accurate representation of what can actually be put into production for other people to use, than those drawn by hand in vector, assuming that a generated design system would be an ultimate source of truth will result in a design system with an equally narrow field of view as its inverse. The component itself, drawn or coded, has very few inherit principles, beyond its affordances, which describe what is known about it. For us to truly know any object, we need to know about every occurrence of that object. To do this would mean to edge slowly closer towards a system as lumbering as the application to which it represents.
Design systems have done much in terms of advocating for and advancing collective thought towards the notion of component-based design and development strategy. By documenting patterns and discussing the application and extension of those patterns, the design system has established a kind of figure-ground relationship between the things that are and are not a part of that system. What is, is recorded, and what is recorded describes what their is.
But a design system is not a library of sketch symbols neatly arranged on an infinite canvas, nor is it a folder of components, or set of pre-made templates. It’s not the dos or the don’ts. And while design systems that are generated from code tend to be easier to maintain and describe a more accurate representation of what can actually be put into production for other people to use, than those drawn by hand in vector, assuming that a generated design system would be an ultimate source of truth will result in a design system with an equally narrow field of view as its inverse. The component itself, drawn or coded, has very few inherit principles, beyond its affordances, which describe what is known about it. For us to truly know any object, we need to know about every occurrence of that object. To do this would mean to edge slowly closer towards a system as lumbering as the application to which it represents.
Design systems have done much in terms of advocating for and advancing collective thought towards the notion of component-based design and development strategy. By documenting patterns and discussing the application and extension of those patterns, the design system has established a kind of figure-ground relationship between the things that are and are not a part of that system. What is, is recorded, and what is recorded describes what their is.
But a design system is not a library of sketch symbols neatly arranged on an infinite canvas, nor is it a folder of components, or set of pre-made templates. It’s not the dos or the don’ts. And while design systems that are generated from code tend to be easier to maintain and describe a more accurate representation of what can actually be put into production for other people to use, than those drawn by hand in vector, assuming that a generated design system would be an ultimate source of truth will result in a design system with an equally narrow field of view as its inverse. The component itself, drawn or coded, has very few inherit principles, beyond its affordances, which describe what is known about it. For us to truly know any object, we need to know about every occurrence of that object. To do this would mean to edge slowly closer towards a system as lumbering as the application to which it represents.
A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. – Alfred Korzybski, Science and Sanity (1933, p. 58)
A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. – Alfred Korzybski, Science and Sanity (1933, p. 58)
We would do well to keep Korzybski in mind when referencing what a design system is and how accurately a design system should seek to represent its application blow-by-blow.
Nothing can be devoid of place and time. For a thing to exist, it must exist at a particular point and place in time. Design systems describe not objects, but possible objects, stripped down and generalized, and do not necessarily reference the relation of an object to its environment. These generalized concepts are things that cannot be fully described until the moment in which they exist again. Only though the application of a pattern in a particular situation can we truly say whether or not that pattern is a well-executed application of a system. The application of most parts of a design system are esoteric, and can only be described though metaphor.
Design system are not rigid rules to be followed. They’re more like sketches, gesture drawings that suggest a shape, a texture, a quality. They are the map. They help guide us towards the right reality, but they are not in and of themselves the reality. So it seems that the best way to describe a design system is spend an equal amount of time not just documenting any given object, but documenting the application of that object in time and space and in concert with all the objects it interacts with. But this is still not the territory. If we go through the process of naming and describing and cataloging a portion of the interface with the intent that the end result is a perfect depiction of the territory of that which it represents, we cannot ever reach objective truth. Any description of any interface would be done with a specifically chosen taxonomy to describe and account for that interface, and the very act of choosing what to say is also a choice of what not to say. We can then look at that map and ask ourselves “what does this map represent?” and thus, we only make another map. Again and again, on and on.
Design systems should aim to tell stories, organized through patterns, which set up scenarios and suggested outcomes. Throughout the description of these patterns, the design system will reference other patterns. Some of these patterns may be more or less gestural than others. When a design that utilizes that design system is being iterated upon, the system should serve as a guide towards more consistent outcomes. When the design is finalized, if a real pattern or object cannot be well-described through a design system, then either the object or the system should be modified to be rationalized through the order of the system, carefully minding that the design system not grow to such immense precision that it reaches an unusable size. I believe this is how design systems can be malleable to new ideas without becoming a tome of prescriptive specificity that everyone dreads.
We would do well to keep Korzybski in mind when referencing what a design system is and how accurately a design system should seek to represent its application blow-by-blow.
Nothing can be devoid of place and time. For a thing to exist, it must exist at a particular point and place in time. Design systems describe not objects, but possible objects, stripped down and generalized, and do not necessarily reference the relation of an object to its environment. These generalized concepts are things that cannot be fully described until the moment in which they exist again. Only though the application of a pattern in a particular situation can we truly say whether or not that pattern is a well-executed application of a system. The application of most parts of a design system are esoteric, and can only be described though metaphor.
Design system are not rigid rules to be followed. They’re more like sketches, gesture drawings that suggest a shape, a texture, a quality. They are the map. They help guide us towards the right reality, but they are not in and of themselves the reality. So it seems that the best way to describe a design system is spend an equal amount of time not just documenting any given object, but documenting the application of that object in time and space and in concert with all the objects it interacts with. But this is still not the territory. If we go through the process of naming and describing and cataloging a portion of the interface with the intent that the end result is a perfect depiction of the territory of that which it represents, we cannot ever reach objective truth. Any description of any interface would be done with a specifically chosen taxonomy to describe and account for that interface, and the very act of choosing what to say is also a choice of what not to say. We can then look at that map and ask ourselves “what does this map represent?” and thus, we only make another map. Again and again, on and on.
Design systems should aim to tell stories, organized through patterns, which set up scenarios and suggested outcomes. Throughout the description of these patterns, the design system will reference other patterns. Some of these patterns may be more or less gestural than others. When a design that utilizes that design system is being iterated upon, the system should serve as a guide towards more consistent outcomes. When the design is finalized, if a real pattern or object cannot be well-described through a design system, then either the object or the system should be modified to be rationalized through the order of the system, carefully minding that the design system not grow to such immense precision that it reaches an unusable size. I believe this is how design systems can be malleable to new ideas without becoming a tome of prescriptive specificity that everyone dreads.
We would do well to keep Korzybski in mind when referencing what a design system is and how accurately a design system should seek to represent its application blow-by-blow.
Nothing can be devoid of place and time. For a thing to exist, it must exist at a particular point and place in time. Design systems describe not objects, but possible objects, stripped down and generalized, and do not necessarily reference the relation of an object to its environment. These generalized concepts are things that cannot be fully described until the moment in which they exist again. Only though the application of a pattern in a particular situation can we truly say whether or not that pattern is a well-executed application of a system. The application of most parts of a design system are esoteric, and can only be described though metaphor.
Design system are not rigid rules to be followed. They’re more like sketches, gesture drawings that suggest a shape, a texture, a quality. They are the map. They help guide us towards the right reality, but they are not in and of themselves the reality. So it seems that the best way to describe a design system is spend an equal amount of time not just documenting any given object, but documenting the application of that object in time and space and in concert with all the objects it interacts with. But this is still not the territory. If we go through the process of naming and describing and cataloging a portion of the interface with the intent that the end result is a perfect depiction of the territory of that which it represents, we cannot ever reach objective truth. Any description of any interface would be done with a specifically chosen taxonomy to describe and account for that interface, and the very act of choosing what to say is also a choice of what not to say. We can then look at that map and ask ourselves “what does this map represent?” and thus, we only make another map. Again and again, on and on.
Design systems should aim to tell stories, organized through patterns, which set up scenarios and suggested outcomes. Throughout the description of these patterns, the design system will reference other patterns. Some of these patterns may be more or less gestural than others. When a design that utilizes that design system is being iterated upon, the system should serve as a guide towards more consistent outcomes. When the design is finalized, if a real pattern or object cannot be well-described through a design system, then either the object or the system should be modified to be rationalized through the order of the system, carefully minding that the design system not grow to such immense precision that it reaches an unusable size. I believe this is how design systems can be malleable to new ideas without becoming a tome of prescriptive specificity that everyone dreads.