# GleSYS Cloud Design System (Bolt?) ### Why we need a design system #### Constraints Compared to other design principles, software design has few physical constraints. This allows us to be very creative and to come up with a variety of solutions to a given challenge, but also allows for an incoherent user experience. #### Several chefs The challenge to create coherent experiences multiplies exponentially as more people are stirring the pot. No matter how consistent a team is, people will create and implement new solutions, diverging the experience. #### Ever-changing Another unique thing about software is that, while what you're building can be considered a product, it doesn’t really wear out and get replaced like traditional consumer products. This requires constant iteration of updates and improvements. #### Agile We're constantly changing direction and when Glesys mission changes we should update the design brief, i.e. the design system ### Purpose of the GleSYS Cloud Design System This is how we think about design, why it matters and where we are heading. We need it to design and we're so proud of our work that we want to show the process behind it. When we write down our collective idea about design it's easier to realize and understand. ### Förslag At GleSYS, we want to create harmonious experiences for our users. We solve challenging interactions and apply the solutions consistently across GleSYS Cloud. Our design system have constraints but also space for flexibility and creativity. We always aspire for GleSYS Cloud experiences to feel: #### Considerate We’re here to make our users day-to-day work better and more efficient by building an inclusive experience. #### Allowing We want our users to feel that they can accomplish what ever they're trying to do. Seamless experience for everyone, give access to more sophistication for power users. #### Familiar We want our users to feel comfortable using GleSYS Cloud whether it's their first or thousand time. Use the same patterns throughout the product for to make the experience intuitive and recognizable. #### Reliable Our users manages invaluable domains and infrastructure with tremendous impact. They should feel certain what their actions and effects will result in. #### Including The customers trust us with their business. We want to allow them to pop the hood and see how things work because we trust each other. (denna säger typ samma som "allowing" fast mer utförligt va? Inte längre :joy:) #### Effective Our users doesn't hang around, they come to us to complete their mission as fast as possible and we should enable them in their endeavour. #### Teaching Infrastructure is complex when things go wrong and very easy when everything is operating. We try to teach our users as they go, picking up information as they get things right. We avoid costly lessons by informing the user when simple mistakes are in the making. ### Design Principles ##### Detail Density (vänster till höger flöde) We show overview first, allow for zoom & filter and finally details on demand.This is done from left to right in cloud v6.0. ##### The price is right (visa pris) We can and will explain to our customers what they will pay and what they have paid for. When creating entities or infrastructure the monthly increase (or decrease?) is visible before taking the action. ##### Law of common region We group infrastructure together on a solid background to help our users to reckognize an entity and make it extinguishable from other entities. ##### Clear and consistent Utilize our component library and guidelines to create designs with good hierarchy and recognizable patterns. ##### Usability first Focus on making a good experience for our customers rather than making it as nice as possible. ##### Language (?) Use clear and consistent words throughout our designs to reduce ambiguity. Give concise explanations and also give the opportunity to learn more elsewhere. Du/ni/er/inget. ##### Feedback is important It should be clear when something is clickable and not. If something is running in the background, it should be clear if it was successful or not after completion. ##### Keep context Limit the use of modals? If your using modals, bring context to the user, since the interface thats behind the modal is no longer visible. ### Best practises #### Guidelines ##### Flow ##### Spacing ##### Colors ##### Hierarchy/typography ##### Grid ##### Icons ##### Feedback ### External documents? * Brand guide * Component library * Icon library