Let's start with a story.



Recently, I was talking about design systems infrastructure at the awesome React Finland conference. The day before the
conference, there was a traditional dinner for speakers. I like this tradition as it makes possible for us speakers to
meet our fellows and the conference organizers so that the next days we work as a team to provide the very best event. As
usual, we were asking each other what the talks are about. When it was my turn, I started to explain that my talk is
going to be about building infrastructure for a design system and particularly a design system website. One person
interrupted me with a question "A style guide?". And that is the key issue. Many people think that **design systems**
are
equal to **style guides**. But they are much more, they must be much more. On this page, I show what is a design system from
different perspectives: design, development, project and even business.



![](./figure11.png)

## What is a design system for me?

We can have a look at who are the actual or potential users of design systems, and what are their professional needs in
this context.


Design systems are often understood as libraries of components. In this regard, the developers are seeing the system
mostly from this perspective. Developers would like to have documentation for every component, examples of usage and
maybe explanation of the implementation details. Apart from that, they would need information related to the whole
system. Such as release notes, instructions for linking the library to the project, etc. For contribution, they need to
know what is the library code style and contribution policy. To give feedback, they need the contact information of the design system team and/or access to relevant boards or chats.



Designers also need documentation for every pattern, especially the reasons behind them. Other design-related
documentation such as color palette, spacing examples, tone of voice, and many more helps them to create new patterns
which are coherent with the rest of the system. They also need information about how to collaborate with other fellow
designers and what are the tools to use. Designers are interested in seeing their creations alive, thus they
need to know how the process goes further on the development and later stages.



Project managers or owners need to have a basic representation of the design system since this is what is used to build the
interface for their product. They are also interested in release notes as in something that has been implemented. Apart from that, managers need to know the design system's nearest future or, in particular, what new components are going to be
released and what are the upcoming changes to the existing ones. For that, managers need to see the design system's
roadmap and learn its strategy as well as be able to discuss this with the relevant people.



On the business levels of the company, especially if speaking about mid-size or large companies, design systems are seen
as internal products and tools. People of this specialization need to have a larger scale picture of the system.
Also, they must be especially interested into design system's meta information such as what is its impact, how it helps
in-team and cross-team collaboration and maybe even the numbers of how much the company earns and saves thanks to the
design system.


## Design system — what is behind?

Design systems are yet evolving concept, our understanding of them is changing. But for sure a design system must serve the
needs of all the people involved in product creation and managing the company. This brings us to the conclusion that **a design
system is not equal to a library of components or to a style guide, it is something bigger**. From my experience, a
functioning and living design system means the following.

#### Shared practices


Design system provides and documents shared practices, based on which you design your product or a bunch of products under
the same brand. A library of components and style guide as their documentation are such shared practices. However,
shared practices are not limited to them but also include more abstract or more design related things such as visual
language or tone of voice. Or on the contrary, they can be deeply technical and reflect your approach to code (aka code
style).


#### Tools


This brings us to the tools which our company could have for all the developers and designers to share. This means
professional software to use and its plugins, scripts for processing and optimizing visuals and code, development and
design environment, etc.


#### Processes

At the next level, design systems would mean the processes which are followed in the company to achieve the outlined
goals. Often spoken that design systems bridge the gap between specializations. This means that the design system should
establish the processes in teams or even on the company level.


#### Community

The processes bring us to those for whom they are created, or to the people. As mentioned above, design systems ensure multidisciplinary collaboration and are meant to help the working collective as a whole. In this regard, having a design
system implies constant work with our fellow developers, designers and project owners as with a community.


## Way to go

A comprehensive design system would have all the aspects listed above; not only a style guide or a library but
documentation and helpful tools for all the practices to follow, outlined and tuned processes for achieving the goals and
helping the routines as well as own community-related documentations, instruments, and actions.

Creating and maintaining the design system is not limited to making visual designs and coding but does include service
design, project and community management. Moreover, a design system tightly connected to brand and business of the company, so the
methods of running it have to be tailored for the specific organization and its teams. These are the topics for
many more articles and discussions (yet published [Maintaining design systems with proper user
research](https://medium.com/elisa-design/maintaining-design-systems-with-user-research-3ba5feafc336) and presented
[Building design systems that leverage your designers, developers, and
products](http://varya.me/design-systems-thinking/)).



Coming back to the story in very beginning, my talk was about documenting all the listed aspects at a company design
system website and organizing the processes for its constant evolving: [slides](https://varya.me/react-finland-2019/),
[video](https://youtu.be/gDkUpx0dVc0?t=9993).



![](./ds-infrastructure.png)


#### Source
This article was originally published at [varya.me](https://varya.me/design-systems/what-is-a-design-system/).

And why it is more than just a library or a style guide

What is a design system?

Design System artifacts whether it is a library of components, UI kit in Sketch, description of UI tokens or pieces of
documentation for the visual language are maintained and developed similarly to regular products. However, usually,
there is a difference. A design system bridges the gap between disciplines and between the teams across the organization, so
it requires involvement of all those stakeholders and their mutual contribution. To make this the most successful, a
Design System needs transparent processes and tools communicating these processes to all the people involved.

According to a research I made in several organizations,
the lack of information is the most painful point for
the usual Design System users. Even well-documented Design Systems face this problem. Often a potential design-system
contributor does not have a focus on Design Systems as a concept and experience in maintaining the
libraries. At the same time, these representatives of the projects using Design Systems are the most important people to
be involved. Developing the actual projects, they have the most knowledge about the business needs of the company
applications and are much more connected to the users than abstract design-system developers. Making these people
smoothly contribute to the Design System ensures its coverage, actuality, and instant expanding as well as saves the
resources. This can be achieved with a very detailed guidance not only for the technical or design aspects of the Design
System but also for its processes.

To start contribution, it is crucial to have a clear vision what to do in specific situations and have a support for
making decisions. This aspect is being actively discussed in the community and some offer their solutions, for example,
Brad Frost presents a decision tree:

![](./pattern-addition-flowchart.png) 
Source: "Maintaining Design Systems" http://atomicdesign.bradfrost.com/chapter-5/

Below, I show an altered version in a form of an interactive component. This is a visual illustration of what happens to a
pattern on its way from identifying the need to actual implementation and how different the path might be depending on the
situation.
This process is called **Pattern Journey**.

## Pattern Journey - Interactive Scheme

![](./pattern-journey.png)

The scheme shows possible paths from identifying the need in a pattern to implementing it. Answers to the displayed questions help to
choose the right way. Note that **you can click on the questions** to get additional guidance on how to get the answer.
For a specific project, the instructions can be more detailed and contain links to communication channels, pages of
documentation, repositories, Abstract spaces or Dropbox.

In the video, you can see how it works.

<iframe width="560" height="315" src="https://www.youtube.com/embed/kKnTN3EswnU" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

## Examples of paths through Pattern Journey

The patterns make different journeys if it is a completely new UI element, changing or expending the existing one or
migrating from a project to the library. Let me show you some (but not all situations). In each of them, a potential
contributor starts from the top of the scheme and goes further navigated with the questions and answers to them. The
additional text is what they see in the popup when they are wondering how they should find an answer to the questions.

### Implementing a new component

![](./pattern-journey__pattern-library--implement-new.png)

Takes steps are:

#### 1. Is the pattern in the library?

You can search for patterns at the Design System / Pattern Libarary website.
Figure out what could be a name or a keyword for the pattern you are looking for, and use if in the website search.

If you don't find anything suitable, you can also ask other people in the
instant communication channels like Slack / Flowdock / Mattermost etc.

Answer: _No. There is no pattern in the library._

#### 2. Anything similar at other projects?

Ask around if people at other projects implement anything similar. You can instantly ask in the
instant communication channels (Slack, Flowdock, etc)
or raise this quesion in regular Design or Develoment meetings. Also, you can ask people directly.

Answer: _No. I could not find anything similar._

#### 3. Can it be used by other projects in the future?

Is there future need for such component at other projects? Discuss this with the other teams, and
do this publically in the
communication channels (Slack, Flowdock, etc).
You can also ask people directly or raise this question at regular cross-company Design or Development meetings.

Answer: _Yes. There are at least two more teams interested in the pattern._

#### 4. Implement the pattern

It seems that you need to add this pattern into the
Design System / Pattern Library.
To start with process, usually you need to create a ticket in the task tracker system
(JIRA, Trello, etc) and/or communicate about what you are going to do directly to the people.
Follow the workflow for implementing new patterns which usually includes task flow, communication standards and code style.

_Wait for release_

#### 5. Use it

Your desired pattern is already a part of the Design System / Pattern Library. Check the
Design System / Pattern Library website
for its documentation.
Use the component as it is documented. If you have question, do not hesitate to ask in the
instant communication channels (Slack, Flowdock, etc).
The suggestions and pull requests for the documentation improvement are very welcome.

### Taking the pattern from another project

![](./pattern-journey__pattern-library--from-other-project.png)

#### 1. Is the pattern in the library?

Answer: _No. There is no pattern in the library._

#### 2. Anything similar at other projects?

Answer: _Yes. The is similar pattern at other project._

#### 3. Can you take it as it is?

Can you borrow the code of this component and use it without any change? So that both you and the "donor" project would
be using the same code?

Answer: _No. It is similar to what I need but I have to alter it._

#### 4. Do other teams ready to use new altered version?

If you change the existing component so that it meets your requirements,
are the current users of it able to use the altered version?
Ask them directly or raise this question publically. As usual,
you can communicate in the
communication channels (Slack, Flowdock, etc).

Answer: _Yes. They are happy with my changes._

#### 5. Implement the pattern

_Wait for release_

#### 6. Use it

### Fix existing pattern

![](./pattern-journey__pattern-library--fix-pattern.png)

#### 1. Is the pattern in the library?

Answer: _Yes. I found its documenttaion and examples._

#### 2. Does it fulfill all the requirements?

Study the pattern documentation at the
Design System / Pattern Library website
and all the examples provided. This way, you can understand if the pattern is suitable
for your specific task.

If there is no example covering your case, but you suppose that it is still possible
without changing its code, play around with example HTML. For confirmation, ask in the
people in communication channels (Slack, Flowdock, etc)
if the pattern examples can be extended with your case. If they can, it would be nice if you
make a pull request illustrating your specific usage.

Answer: _No. It is close what I need but I need extended functionality._

#### 3. Can it be changed to suit your new requirements while still fitting existing requirements?

Figure out the requirements for the existing component based on the documentation and examples. If you have doubts, ask in the
instant communication channels (Slack, Flowdock, etc), at regular meetings
or in person.

Does it look that you can provide changes and the component will not be broken in the places it is used now?

Answer: _Yes. I can provide changes, and nothing will be broken._

#### 4. Implement the pattern

_Wait for release_

## Usage

This decision helper is meant to be a part of a Design System documentation. Being a React component it can be easily
altered due to the needs of a specific company or product. Similarly, it can be constantly updated while the processes
in the Design System are changed and shapen.

#### Source
This article was originally published at [varya.me](https://varya.me/design-systems/pattern-journey/).

A process of maintaining and extending design systems

Pattern Journey

Both User Centered Design (UCD) and Agile Software Development (ASD) are widely used methods in the production of user interfaces (UI). However, they “frequently putting contradictory demands on people working with the respective processes” (Jones, 2019). Trying to match different disciplines, the designers and developers are supposed to conduct alignment work which brings them to mutual understanding in the context of their work, revealing “design breakdowns” (Maudet, Leiva, Beaudouin-Lafon & Mackay 2017) early enough. 
This research aims to find what designers and developers who consider their collaboration process as successful value in each other.

## Research design

To obtain data of what is designers’ and developers’ perceptions of working with each other, the researcher collected recommendations from LinkedIn profiles. For the final data analysis, there were selected profiles of _7 designers_ and _9 developers_. The recommendations were filtered so that for developers it was only recommendations from designers (and not from people with other roles), and for designers it was only recommendations from developers. The roles of the people were taken as they identify themselves in their LinkedIn Profiles.

![](./recommendation-example.png)

## Codifying

For the codifying, the data was collected into one document, anonymised and processed with the help of ATLAS.ti. Full text can be found in Appendix 1.

In the text of recommendations, the researcher outlined _1st level concepts_ — the attributes that colleagues highlighted as valuable. The concepts were unified into _themes_ following the area which they belong to. The list of concepts by themes can be found in Appendix 2.

The themes were aggregated into _dimensions_ forming the following scheme.


![](./codifying.png)


The dimentions are 1) Wideness of expertise, 2) Hard skills, 3) Professional attributes, 4) Soft skills, and 5) Personal attributes.

Wideness of expertise includes knowledge of the technical aspects for designers, understanding of design (particularly, UX) value for developers and knowledge in the business domain for both roles. Hard skills assume direct role-related knowledge and being good at collaboration. Professional attributes list the properties which contribute into both hard and soft skills. Soft skills are the factors positively affecting communication. Finally, personal attributes ease communication and break the barriers.

## Discussion

The “wideness of expertise” dimension attracts the most. It is noticeable that designers and developers very much value if their colleagues have some knowledge in their area of expertise. These facts resonate with the findings of factors of successful collaboration between UX designers and UI developers. There, the developers complained about “designers do not know enough about the technical limitations when designing solutions” (Jones, 2019). In particular, the developers mentioned that static designs tend “to lack necessary details about the interaction layer in-browser” (Jones, 2019). Similarly, another research mentions the developers’ complaint regarding collaboration with designers as “designers usually don’t take into account the dynamic nature of the data” (Jones, Volker & Gemma, 2016) Generally, the sharing discipline specific knowledge “allows for in-depth discussions about the technical opportunities and constraints of different ideas” (Jones, 2019) and “collaboration is usually smoother when the designer is aware of the developer’s constraints and possibilities” (Maudet et al. 2017) .Correspondingly, the recommendations’ analysis shows that developers value “prototyping” skills of designers which would bring them dynamic designs including the interaction details.

In addition, both designers and developers highlighted business and product knowledge as positive.
This is probably because both designers and developers would like to make mutual decisions regarding the creating product and seeking the missing expertise in their closest colleagues. The value of same-domain expertise can be explained as first the professionals would like to be sure that they can rely on their colleagues' decisions, and for that they validate the colleagues’ knowledge in the area where they themselves are professionals.

Overall research findings complement the studies which outline that “successful collaboration between designers and developers can be found through the following six factors: 1) Close proximity, 2) Early and frequent communication, 3) Shared ideation and problem solving, 4) Crossing over of knowledge and skills, 5) Co-creation and prototyping and 6) Making joint decisions” (Jones & Thoma, 2019).

## Conclusion

The conducted analysis demonstrated correlation with the existing studies. Even though the obtained data was selected randomly and was less than 20 short recommendation texts in total, it allowed to categorize the valuable attributes of designers and developers and showed the match in valuing cross-disciplinary knowledge. The research approach and the method of obtaining data look as a promising contribution into the following study of positive factors for designers’ and developers’ alignment work.

- [Appendix 1. Raw data](https://varya.me/designers-developers-linkedin-study/Varya-Stepanova__What-UX-designers-and-UI-developers-value-in-each-other__LinkedIn-study__appendix-1.pdf)
- [Appendix 2. 1st-level concepts and themes](https://varya.me/designers-developers-linkedin-study/Varya-Stepanova__What-UX-designers-and-UI-developers-value-in-each-other__LinkedIn-study__appendix-2.pdf)

## References

Jones, Alexander J. 2019. “Factors for Successful Agile Collaboration between UX Designers and Software Developers in a Complex Organisation Item.” Doctoral dissertation, United Kingdom: University of Chester.

Jones, A., & Thoma, V. (2019). Determinants for Successful Agile Collaboration between UX Designers and Software Developers in a Complex Organisation. International Journal of Human-Computer Interaction. https://doi.org/10.1080/10447318.2019.1587856

Jones, A., Thoma, V., & Newell, G. (2016). Collaboration constraints for designers and developers in an agile environment. Proceedings of the 30th International BCS Human Computer Interaction Conference, HCI 2016.

Maudet, Nolwenn, Germán Leiva, Michel Beaudouin-Lafon, and Wendy Mackay. 2017. “Design Breakdowns: Designer-Developer Gaps in Representing and Interpreting Interactive Systems.” In Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing, 630–41. Portland Oregon USA: ACM. https://doi.org/10.1145/2998181.2998190.

#### Source
This article was originally published at [varya.me](https://varya.me/blog/designers-developers-linkedin-study/).

The knowlegde we share

What is a design system?

Pattern Journey

What UX designers and UI developers value in each other. LinkedIn research study