arrow一覧に戻る

2021.10.20

デザインシステムでアニメーションを使いましょう

English version is below.

サマリー

この記事では、アニメーションとモーショングラフィックスをデザインシステムに実装する方法と画面を作成する際にそれをどう使うかを紹介します。

アニメーションは、映画のような物語性を持った作品でよく使われるだけあって、ストーリーテリングと密接な関係があります。アニメーションの最も特徴的なリソースは時間です。時間の流れに沿って何かを伝えるものです。UI/UXデザインでアニメーションを検討することはありますが、活用できる時間はかなり制限されることが多いです。UIの動きで何かを伝えようとしても、一瞬で終わることが殆どで、時間をかけてしまうとユーザーは苛立ちを感じることになります。しかし、アニメーションをうまく駆使するとその短い時間に製品の個性を伝え、ユーザーをより夢中にさせることができます。従って、色や形、フォントなどのデザインの道具と同様に、動きもインターフェイスの個性を表現する手段のひとつで、製品のブランド感を作り上げるために役立ちます。

デザインシステムにもアニメーションを含めることが良くあります。しかし、アニメーションやモーション関連のガイドラインが適切に記載されているデザインシステムはかなり少ないです。それ故に、デザインシステムを使っていても、デザイナーに意図が明確に伝わらず、場合によっては本来の意図が完全に変わってしまうことがあります。

アニメーションのガイドラインは、静止したUIのガイドラインとは表現すべきものが異なります。時間の間に起こる動きを伝える必要があるため、ストーリーボードや実際の動画、あるいはCSSのキーフレームを使うことで、動きを表現する必要があります。できれば実装されたコードが再利用できるサンプルとして提供された方が、間違いを最小限にする方法となります。このような理由から、デザインシステムはアニメーションもしっかりガイドラインとサンプル付きで提供する必要があります。

デザインシステムにアニメーションを格納して共有する方法として、以下の3つのステップでのアプローチが有効だと思います。

  1. リファレンス調査:既にある参考になれるデザインシステムを調べます。調査の際には、自分のデザインシステムで必要なものを意識して、自分のケースに関連するものだけを見極めることが大事です。また、自分のプロダクトも調査し、既に使われているアニメーションがあるか調べる必要もあります。
  2. 下書き:アニメーションのガイドラインのドラフトを作成します。UIの要素の動きとその持続時間、エフェクトの有無など、必要な情報を分類して記載し始めます。持続時間、イージング、エフェクトなど先ずは簡単なものから始めても問題ありませんし、形式も簡単でもいいかと思います。
  3. テスト:上記のガイドラインが実際にうまく機能するかを確認します。デザイナーが自作するか、またはエンジニアに実装してもらい、ユーザーテストを行い、その効果を確認します。十分機能することが確認できたらデザインシステムに反映します。それで終わり、ではなく、4つ目の(隠れた)ステップに進みます。それは反復することです。デザインシステムの他の部分と同様に、絶えずに改善を行います。

しかし現実的には、アニメーションのガイドラインがデザインシステムに掲載されていても、それが読まれることも稀であれば、それに従って充実に実装されることを期待するのも、規模の大きい組織では難しくなります。そのため、すぐに再利用できる、動くコードを用意することが求められます。

開発のプロセスの話に戻し、デザイナーからプログラマーへのハンドアウトについて考えてみましょう。アニメーションの場合は何を持ってハンドアウトするのか。テキストのガイドラインを書いてもいいのですが、結局はプログラマーの解釈に任せられることになります。本文中ではHead氏の言葉を借り、ハンドアウトに使える成果物の例としてストーリーボードやスケッチモーションコンポジションインタラクション・プロトタイプなどを挙げております。

アニメーションの制作を依頼する際には、最低限、動きの流れを伝える必要があるので、ストーリーボード(絵コンテ)で動きを表現します。モーションコンポジションは、実際に動いているものを表現するアニメーションのひとつですが、これには特殊なスキルやソフトウェアが必要になるという問題があります。最後は、インタラクション・プロトタイプです。これを作るためのWebアプリや、既製のモーションが含まれたライブラリが多数あります。しかし、HTMLやCSS、Javascriptを駆使できるデザイナーがいるなら、実際にコードを書いて、CodeSandboxやCodePenなどで共有する方法もあります。

デザインガイドラインと共に実際に動くコードをデザインシステムに入れておけば、そのまま入手して使うことができるので、不意な改悪なども防げますし、プロジェクトの開発の工数を減らすことができます。もちろん、イージングやデュレーションなどのプローパティを制限するための原則やルールの提示は必要ですが、実際に動きがみれるものを用意することがとても大事と言えます。

Using Animation in Design Systems

Using time as a design tool

In this article, I want to share some findings on how animation and motion graphics can be implemented in Design Systems along with some personal experience related to animation in general and its usage when creating UI/UX.

Let’s start with some personal experience: as a 90s kid, I grew up watching fantastic 2d characters behind the television screen. This became the trigger of a long journey that brought me to Japan, as I first felt interested in Japanese culture because of watching anime series that arrived on the other side of the world. Animation also became a big interest for me. I remember learning Flash in high school, using motion tweens and keyframes. Some years later I took animation classes as an undergrad student. Then, I got to experiment with different techniques: traditional, rotoscope, stop-motion, cut-out, 3D. Even when I came to Japan, years later, I had the opportunity to be a teaching assistant for a 3D animation class for some years. I ended up using animation more as a tool rather than an artwork in itself. Nevertheless, I was able to get the very precious knowledge of what was behind those 2D characters of my childhood.

Animation is not only for narrative cinematographic works, but it is also very well connected to the idea of storytelling. After all, animation’s most unique resource is time. You can use drawings, computer graphics, paper, or clay, but what you are actually playing with is time, and what you can convey during that span. When we talk about animations in the context of UI/UX, we actually don’t have much time, to begin with. There are mere instants to convey something before it becomes too long for the user and ends up frustrating them. Still, in these fractions of seconds, you can convey the personality of your product, and possibly, make your users feel more engaged with it.

Pulling out memories of those animation classes I mentioned above, I remembered a concept about providing a character with a personality only by determining how it looks when it walks. Making a proper character walk-cycle is one of the most fundamental and difficult things in animation, but it can grant a character uniqueness and personality in only a couple of seconds. I would like to showcase these sets of parallels between movement in Val Head’s talk about Motion in Design Systems (28:25) and Caleb Barclay’s article (in the Easing section). In both cases, you have some characteristics that you want to convey in less than a second. If you take a look at these characteristics, they might as well be animated character descriptions. More than wanting to anthropomorphize an interface, behavior that can be associated with human ideals can be useful for transmitting those ideas to the user. Movement is another tool that can represent the personality of an interface; the same can be said for color, shape, fonts, and other design tools. It can aid to strengthen the brand of whatever product you are showing.

Animation in design systems

Design Systems may implement motion in their guidelines. Nevertheless, as noted by Head, in Sparkbox’s designsystems survey, only a minority of systems choose to have animation or motion-related guidelines. Currently, “Animation System” appears as the second-lowest survey item answering the question”What does your design system contain?”. Why is this? Probably not all design systems might need animation. However, since it is another design tool, designers may opt to use it. If designers decide to implement animation and there are no rules on how to apply it, it becomes a guessing game and movement can compromise the original intentions of any design. Going back to the why, I can only really assume, but I believe it has to do with the same issues we have when using animation in a UI development workflow.

Head points out that in UI/UX, animation is often done as an afterthought, a decoration that you put at the end. It’s quite understandable that animation gets relegated to the second plane. In a complete production process, you have to go between client, designer, and coder, make fixes to already implemented components, and re-design parts that don’t work anymore. Of course, you might touch on animation here and there: a simple color transition in a button, a menu opening, and closing, but most of the time there are no clear guidelines on what things should look like. In the end, it just falls to asking the designer to approve an animation or ask for a change. Animation guidelines go beyond having your static UI on Figma or a similar dedicated UI/UX software. You need to convey movement, either by creating storyboards, an actual video, or better, the CSS animation keyframes ready for the coders to use. Unfortunately, this is an extra step in production that most will probably not undertake.

The above might actually be the very reason why you should consider adding animation to your design system. Even if it’s just a general outline of how it should be used. Of course, the more you expect to be using animation in the interfaces made with your design system, the more you might want to consider more specific ways of guiding your users.

How to implement motion in design systems

Actually, I don’t know. I haven’t tried to make animation guidelines yet, but bringing up again Head and Barclay‘s articles, and also adding here Yalu Ye, and Grishma Devatar, it might all come to three (very familiar) steps: Research, Sketch, and Test.

Research already existing design systems and how they display motion. The articles above already have their own compilations and analysis of each. It might seem obvious to check for references, but you might also want to consider reasons to choose a reference over another. Audi is inspired by their own cars, Brand Estonia seems to embed movements found in nature, while Google’s Material Design wants to be as thorough as possible. It is important to have your Design System’s general guidelines in your head at all times. When looking into references, be conscious of what you actually want to convey through your design system, and identify either what is related to your case or what distances from it. Consider also reviewing your own design system, you might already have motions that you haven’t identified. Barclay refers to this as an Audit, and suggests making documentation to sort out the information of what you already have.

Sketch is, exactly that, sketch out the guidelines. You might already have an idea of how you want things to move around, for how long, whether they have any effects, how these guides can be categorized, etc. Here are categorizations of guidelines by Head, Barclay, and Ye:

Val Head

  1. Duration, Ranges, and Rhythm
  2. Easing Values (Essential Easing Functions: Ease-in, Ease-out, Ease-in-out and Easing hierarchy)
  3. Named Effects

Caleb Barclay

  1. Duration
  2. Easing
  3. Effects
  4. Choreography

Yalu Ye

  1. Duration
  2. Easing
  3. Properties

They are not that different. Sure, they use more or less the same Design Systems as a reference, but this actually gives us a solid background on what we should be drafting for our guidelines. Personally, among the examples above, I would prioritize Barclay’s example as it is the only one to show actual animations (!).

The final step is to Test. Check if the guidelines you are proposing actually work. Test with your team and users, and compile observations and data for the secret fourth step: Iterate. As with other parts of a Design System, revisions will happen, and improving what was first planned is a necessary step for any development.

With this last step, we might come to the realization that the whole guidelines we planned are actually pure gibberish: a wall of text that won’t be read and much less used. This is where the other fundamental point for implementing animation lies.

Presenting motion

This goes back to what I mentioned some lines above about considering an actual workflow. Let’s think about the handout of animation specs for UI from the designer to the programmer. What should it be? You could write up some guidelines but it would probably end up being left to the programmers’ interpretation and a subsequent back-and-forth discussion. Head gives some examples of what the handout could be, the possible deliverables: Storyboards and Sketches, Motion Compositions, and Interaction Prototypes.
I would say at the minimum when asking for animation, you have to sketch up what you are talking about in a sequence. Make Storyboards to present movement. Otherwise, it would be like sending a pure text document explaining what is inside each screen instead of having a UI designed in Figma. Head presents three points for storyboards:

  1. Trigger: What starts the action? Draw or describe in words.
  2. Action: What takes place? Draw in as many frames as needed.
  3. Quality: How does it happen? Describe in words.

Motion Compositions are another option for demonstrating animation, and they actually present things moving. The problem with motion compositions is that you require an extra set of skills and software: learning to make compositions in AfterEffects or searching for a web app that lets you make videos that in the end will only serve as a reference and not be actually used in production. The exception is if you actually need a gif or video that will be shown as it is in the UI, but if the animation has to be redone in CSS, it might not be worth it, even for Design Systems.

This leaves us with the last point, Interaction Prototypes. There seem to be a plethora of easy-to-use web apps for making animations, and libraries with ready-made motions. But, if you have a designer who is also able to use HTML, CSS, and Javascript, you may as well just ask for the actual code and share it in CodeSandbox or CodePen. And if you set the animation with its functional code in your Design System, it will be easier to understand and to use, as you already have something to grab and use as it is. Of course, you still need some pointers and suggestions on limiting the easing, duration, and other attributes. However, if you provide a starting point that you actually can see in action, it will make things easier.

Conclusion

You wouldn’t present a button in a design system as a block of text explaining what a button should look like. In the same way, you cannot depend only on text for describing how motion should behave. It is necessary to document duration values, easing patterns, and effects, among others. But if you don’t show what it actually looks like in some way, it might be harder to adopt. Having simple ready-made code to use will always make programmers extra happy.

この記事を書いた人

モレノ キロガ ハコボ フロントエンドエンジニア

南米コロンビア出身、ハベリアナ大学(コロンビア)社会科学部文学科卒。2013年に来日し、九州大学芸術工学部の修士・博士を取得。 大学院の研究ではゲーム性を取り入れたデジタル教材をテーマに、ゲームエンジン、3DCG、モバイル開発など、プロトタイプを作成するための技術を習得し、コンセプトから実証実験まで行った。 卒業後、AIのスタートアップ企業でデザイナー及びフロントエンドエンジニアを経験。 UI/UXデザインのメソッドを身にづけ、Webアプリケーションの最新技術を使い、AIを取り入れたアプリケーションのUIデザイン及びフロントエンド実装などに従事。 2020年8月にエンジニア兼デザイナーとしてFixelに入社。

Contact

どのようなお悩みでも
まずはお気軽に
ご相談ください

arrow

Careers

柔軟で先進的な思考を持った
デザイナーやエンジニア、
コンサルタントを募集しています

arrow

Copyright© Fixel Inc. All rights reserved.