Making documentation of design systems easier for designers.
Blurb
Everyone knows writing documentation is the worst, but having it is the best. Despite this, documentation is often a low priority. Doction aims to help designers document their design systems by integrating with their design tools, thus allowing for seamless documentation and make the most of their design system.
Based on the feedback I am reworking the value proposition and being more clear and details about the concept.
Target Market
For: designer Who Need: to document their design system But: don't necessarily want to get into code or use external tools
Value Proposition
My offering is: a plugin Including: a style guide website That: integrates with the design tool Which: makes hand-offs among designers and developers seamless
Competitive Position
Unlike: other tools like Zeplin, Frontify, etc. Solution: Docur gives you flexibility and ease of updating your documentation.
Version 1:
Docur is a plugin for designers who want to document their design system and create dynamic style guides for digital products, which acts as the single source of truth. It integrates with the design tools, making hand-offs among designers and developers seamless. Unlike other tools, Docur gives you the flexibility of customising and ease of updating your documentation.
Version 2:
Docur is a plugin for designers who want to document their design system and create dynamic style guides for digital products. It integrates with the design tools, making hand-offs among designers and developers seamless. Unlike other tools, Docur helps in keeping documentation upto date with design and be the single source of truth while giving you the flexibility of customising and ease of updating your documentation.
Docur is a toolkit for designers and front-end developers who want to efficiently create dynamic style guides for digital products. It acts as a bridge, making hand-offs between designers and developers seamless. Unlike other tools, Docur helps in keeping documentation upto date with design.
Yes, Una Kravets! Yesterday I had my first advisory meeting with her, and it was a very fruitful conversation.
We kicked off the meeting by discussing the plan for the rest of the semester. We agreed upon discussing the progress of my MVP (minimum viable product) and also getting feedback on my in-class assignments like value proposition, prototype plan, competitive analysis, etc. every time we meet.
Value proposition
I got feedback on what works well and what doesn't. A few thoughts from Una were to make it clear how my product "acts as a bridge", "from design(Sketch) to code" and helps "keeping documentation upto date with design". I will be working on a new version of the value proposition which I will share soon.
Concept
I demoed my current working prototype that I had been working on since a week and going back-n-forth with the technical architecture. Una suggested I should not get stuck with the technicalities for now, just pick something for the MVP and focus on the interaction.
We discussed:
What to use for the MVP?
Metalsmith, a pluggable website generator that I can easily customise to fit the need.
How does the interaction from Sketch to the documentation website look and work?
This is something that I even got feedback from the rest of my class and have been thinking about refining it. I will be talking about this in another blog post.
A big question that popped up was — Why does the designer even need to get into code to write the documentation? Can't it just happen in the Sketch plugin. Quoting Una here:
"Writing notes without even touching the text editor"
I am going to sit on these questions for a while and think of the answers.
Docur is a toolkit for designers and front-end developers who want to efficiently create dynamic style guides for digital products. It can combine design documentation with their design workflow, making hand-offs between designers and developers seamless. Unlike Brand.ai, Docur is a static-site and gives you complete control of customisation and flexibility.
Second variation
Docur is a toolkit for design teams to document their design systems in order to educate the rest of the product team about design and implementation guidelines. Unlike other documentation tools, Docur generates a documentation website which serves as a dynamic style guide.
In my last post I spoke about Airbnb's Lona and Docur, my prototype. Here are the answers to a few questions to reflect on the current state of my thesis.
What was the strongest component of your prototype?
I think what I can do different and benefit both designers and developers is utilizing the power of Lona to generate the design systems documentation is a much more flexible way. Since Docur is a coding kit, it gives you an option to extend and customize it.
What was the weakest component of your prototype?
The weakest and in fact, the most challenging part of my prototype is the ability to render components on the documentation website. Can I make the component render just as it was designed? Apart from just the look of it, can I make the component functional or at least offer an ability to make it functional?
List the areas in your thesis concept to further explore for:
Interaction
Is a Sketch plugin the best way?
What about tools apart from Sketch?
Design
The documentation website will be shipped with a default theme, what is the best way to extend or custom that theme to fit the design systems need.
Technical
Is static site generator the best way to go?
Can there be a better way to integrate a design and the Lona file?
What are existing attributes of your thesis concept to further refine and iterate?
I believe that the documentation website itself is the core of the concept. I need to architect in such a way that it is both adaptable and scalable.
What new areas have you not yet explored that are really essential? If they're not essential, can you rule them out to simplify your path moving forward?
I still need to explore more opportunities and case studies of previous attempts of automating the generation of style guide from CSS, SASS, etc for example like KSS and SassDoc. Also design tokens! A “design token” is an abstract bit of design language that normally becomes visible only when applied to more explicit patterns and components. For e.g.: Colors, fonts, scales, and grid-configurations. I still need to throughly think of the best way of handling them in the documentation.
In thinking about the user's experience what phases have you overly focused on? What parts of the experience have gone under-explored?
The plugin to export from a design tool is something that needs to be further explored since it may vary from tool to tool.
"A tool for defining design systems and using them to generate cross-platform UI code, Sketch files, images, and other artifacts." - source
How does Lona work?
A design system is defined in JSON as a collection of components, styles and data types. The specification for these files can be found in the docs.
Lona has 2 parts to it — Lona Studio, a GUI to work with these .component & JSON files & Lona Compiler which converts the files to UI code for various targets.
How can others benefit from Lona?
At the core of Lona is the .component and JSON files which specifies how and what of a component. This is essentially what your design system is built-up of and hence the translation from design to UI code is what makes Lona efficacious. The potential of Lona also makes it a very useful tool to document your design system.
Coming back to the prototype:
What's the problem?
A very crucial part of a DS is its documentation, without which it is very difficult to use one. For example, which colour to use when? or when to use a solid button vs outlined button?
In my prototype proposal I talk about how documenting design systems is a problem and needs to be tackled.
The current scenario from design to documentation is very time consuming and inefficient, to put it visually, like this:
There is only a connection between your designs and its documentation.
There are few things that don't work here:
Development: Like I said there is only a connection between the designs and its documentation, but no overlap or intersection of its content. And because of this you have to get into code and build the documentation. Hence it is a manual process, hence lengthening the entire process.
Customization: if you use a tool like Brand.ai or Frontify, there are very similar to Squarespace or any hosted service, you can't get complete control over your documentation's look n feel or even functionality.
Time: documentation is crucial but often either neglected, pushed to later sprints or often outdated.
Hypothesis
I believe that if I make a tool that can integrate with the design softwares, then designers will be able to document their design system conveniently.
Solution
Docur - A tool for documenting design systems to educate teams about design and implementation guidelines.
How does it work?
Step 1: Export
Export your designs from the design library/UI Kit.
This will generate a Lona data file that we saw above 👆.
Step 2: Copy to Docur
Docur directory structure
Step 3: Generate documentation
The documentation
Benefits
Docur is not a cloud-hosted solution or even dependent on the design software in-order to work, it integrates with any tool that can generate the data file for it to work.
Docur is smart enough to parse the data files as long as they follow a predefined specification.
Docur's website is a bunch of static code, pretty easy to understand and learn, that makes it possible to easily customise and extend its functionality.
If you choose not to dive deep into code, that's fine, the documentation is simply written in Markdown and hence is nothing barebones or time consuming like raw HTML.
After doing just enough research about design systems, the one problem that I discovered and decided to focus on was about documenting design systems. For this prototype, I am going to focus on small teams, who may only be working part-time on a design system.
Results from the survey
User Flows
Before I talk about the hypothesis, let's look at a few scenarios for building a product, along with a design system.
Scenario 1
Establish a style guide (or a brief design system) first, then make designs & build product simultaneously, while iterating on the DS alongside.
Scenario 2
Make designs, rapidly build a product & launch, then start making a design system and iterate on both.
Looking at scenario 1 & 2 we can see that the documentation of a design system is pushed to towards the end of the process. In most cases, this is due to limited resources and time.
Scenario 3
Make designs, build a design system, then build a product and iterate on both.
In the 3rd scenario, we see how a design system is set up first and used to build a product. The only problem with this scenario is that the time to launch the product is longer, and in most cases, the documentation is skipped to launch quickly.
Hypothesis
I believe that if I make a tool that can integrate with a design tool then teams will be able to create and manage their design system's documentation easily.
Idea
My initial idea is to create a bridging application that integrates with the current design tools and extends it’s functionality to help document a design system.
System Diagram
Ideally, let’s say you design something in Sketch, you would then write specs and hand it over the the developer to build. But what if you could document your design as you are designing it? This takes the documentation overhead off a developers shoulder.
Prototype
Plugin shows selected layers along with information that can be extracted
Imports the designs in a web-based design system manager
Revised system diagram —
Conclusion
This prototype does raise a few question like what are the limitations of generating a documentation like this? How can I make it more intelligent to improve generation of specs? Will it only contain static images of the layers? At what point does the developer come-in? How is this different that the existing tools?
My next steps are to find the answer to these and also test this prototype.
Last week, I spend some time researching about the design tools landscape. This week I dove into design systems — what they are? How are they created, used and managed?
What does a Design System consist of (mostly)?
Building Blocks
Color Palette
Typography
Grid & Sizing
Icons & Assets
UI Patterns
Elements
Components
Templates
Modules
Rules
Design Principles
Implementation Guidelines
Content Guidelines
What tools are people using to create and manage design system?
Design Systems are a not small, and like I mentioned previously most bigger organisations have a dedicated team for creating and maintaining design systems. These organisations have custom tools and a setup to create a system that fits well for their set of products, like Airbnb using the React-sketchapp tools to design with live data.
Although, some organisations use tools like UXPin, Pattern Lab, Fractal, StoryBook, Astrum, etc. to quickly and efficiently make a design system and generate a pattern library.
After the first pitch of the idea in class last week, a big question that came up was —
Do you want to make designing better or designing faster?
I didn't really have an answer to that question. I started doing some desk research to answer a few preliminary questions —
Design tools
Source
What are the current tools that people are using for designing?
Sketch (over 60% of the community), Figma, Adobe XD and others
What are their pros & cons?
Sketch
Pros
Works offline
Plugin support
Native software, resulting in better performance
Cons
In the end, you need to export the designs to make anything out of it
Lacks built-in commenting
Prototyping can be done only using plugins
Only available on Mac OSX
Figma
Pros
Collaboration
Built-in prototyping & commenting
Generate design documentation
Cons
Web based, performance not that great
You can only export PNG, SVG & JPG
Lacks plugin or 3rd party support
Adobe XD
Pros
Works offline
Built-in prototyping & commenting
Free of cost
Cons
No tools for documentation
No collaboration
Lacks responsive designing
Only basic and non-responsive symbols supported
What happens after designing is done?
For most tools the end result of designing is export to images. Although tools like Figma, UX Pin and Atomic.io also support drawing shapes and making click-through prototypes. Typically, these are then documented, spec'd and handed over to the developers.
Next step for research...
Design Systems
Creating
What tools are people using to create design system?
What are the challenges they are facing?
Implementation
How is the handover from a designer to developer?
How is the designer-developer experience?
Managing
What tools are being used to manage a design system?
In my previous post, I mentioned various thoughts and observations about a Design System (DS), most of them being benefits of having one.
Here are a few of ideas around those observations that I have in mind —
1. Building a DS
Making a design system consists of multiple steps — discover, design, build, documentation, and publish. It is not a small task, most companies have a team dedicated to just creating and maintaining design systems. For e.g. Lightening Design System by Salesforce, Ant Design by Alibaba. How can we make it easier and efficient for design teams to make a design system?
Brad Frost’s influential Atomic Design methodology put forward a more structural approach. Rather than a jumble of “atomic” elements scattered across a screen (e.g. a label, an input, a button), Atomic Design suggests that a small collection of UI elements should be thought of as a meaningful component, (e.g. a page footer, a login form).
Google’s Material Design guidelines pushed the concept further, bringing deeper formal rationality, a bold aesthetic and resources & guidelines for building UI elements across a range of platforms.
There are frameworks like Bootstrap and Bulma that are nothing but pattern libraries. Yes, they allow you to keep all of the smallest elements consistent. But they don’t have an opinion about how they should be put together. They don’t know anything about your product or the concepts behind it.
Key points:
Building tools for creating a design system
Better process and planning for a system
2. Using a DS
Design system is a recipe that helps designers to run the “kitchen” smoothly. By using the same recipe, designers can keep offering quality “dishes” to customers. It also acts as a live library that has all global components can speed up the development process. How can we utilize a design system to benefit the team & the users?
Here is a demo of how Airbnb is planning to use it:
Key points:
Building tools for using a design system
Quicker prototyping and designing
Helps in scaling your product
3. Fix the design tooling
Even the most “advanced” digital design tools are based on workflows for drawing mere pictures of interfaces. — Daniel Eden
Almost all popular design tools export to images. This is problematic for a number of reasons like you cannot interact with images (static), they are not fluid and they are not stateful. How can we make the design tooling better?
Quick demo of a sketching tool that recognizes shapes and pulls in known interface elements from a component library. pic.twitter.com/QFEwT0LfMI
We’re not designing pages, we’re designing systems of components.
A design system is necessary to achieve the W3C design principles for the architecture of the web like modularity
Pattern libraries are made from a design to simply provide helpful documentation, although as the product advances, the library becomes obsolete. They are just one part of a bigger design system.
Taking the "design system first" approach, and then, deriving the designs and a pattern library from that system. 1
A unified design system is essential to building better and faster; better because a cohesive experience is more easily understood by our users, and faster because it gives us a common language to work with. 2
A solid design system can reduce the amount of effort required to keep features and designs synchronized, often requiring the same work to be repeated across all of the platforms.
Creating design systems will give us the flexibility we need for working with the unknown devices of the future.
Working with multiple teams results in multiple processes and codebases. The design system is an attempt to bridge the divide between these codebases, establish a more collaborative environment, and to empower each team to efficiently build consistent, accessible experiences.
A well-defined design system consists of — Style palette (colours, spacing, sizes, etc), assets (icons, illustrations, etc), component library (buttons, inputs), modules (tabs, menus, forms) and screens (collection of modules, components and data).
Designing for the next largest context. Think of your UI in the context of the system it exists in (the next larger context). A button in a form, a form on a page, the page in the browser, etc. Components should be designed to live in and adapt to different contexts. 3
Now as the product grows, there are multiple problems that arise for both the front-dev and the designs of the product, for example, consistency across your product to create a cohesive feel.
2087
vaporwave
stormborns
kianamaiart
yousharknotpass
izzy806
germansingergirl