arrow一覧に戻る

2021.07.20

Trying out UXPin’s Merge and its Storybook integration (UXPinのMergeの新機能、「Storybook連携」を試してみました。)

English version is below.

紹介文

UXPinからMergeのまだ公開されていない「新しい機能」を試すチャンスを頂いたので、デザイナーとエンジニアのコラボレーションという視点での感想を、直接試した弊社のエンジニアが以下にまとめました。(ちなみに、この文書の公開時点では対象機能は既に公開されておりますので、いつでも試すことは可能です。)

参考までに、UXPinは既に広く使われているデザインツールで、UXPinだけでデザインとプロトタイプの作成が可能です。他のデザインツールとの差と言えば、コードに親和性が高いツールで、プロトタイプでできることが他のデザインツールに比べ柔軟かつ多様であることです。

MergeはさらにReactベースのUIコンポーネントを実装したコードを使って、UXPinと同じ使い方で迅速にプロトタイプの作成ができるツールです。そのMergeに今回新機能として「Storybookとの連携」を追加したわけです。

MergeをStorybookと連携して使うための作業フローは下記のようになります。

  1. UXPinを使ってデザイン
  2. Storybookを使ってUIコンポーネントを作成
  3. Storybookで作成されたUIコンポーネントをGithubのリポジトリーに保存
  4. MergeからGithubのリポジトリーにアクセスしてUIコンポーネントを取得
  5. 取得したUIコンポーネントを使ってプロトタイプの作成し、新しいUIの有効性を検証
  6. 検証が終わったプロトタイプを参考に、プログラミングを行う

上記の手順からStorybookの使用は必須ではありません。しかし、Storybookが既にある程度普及されている現状を踏まえると、Storybookとの連携は賢いアプローチだと思います。

ここで一つ残念なのは、手順5で作成したプロトタイプを手順6のプログラミングの段階でそのまま使えないことです。つまり、実際のプロダクト用のコードは自前で作成する必要があります。(まあ、それはまた将来の拡張に期待を寄せるしかないですね。)

恐らく、Mergeの狙いはデザインシステムから提供されるUIコンポーネントを使って迅速にプロトタイプを作成することだと思われます。

UXPinの方々とも議論しましたが、Mergeが活用されると期待される環境は、ある程度規模のある企業で、かつデザインシステムの専門チームと各プロダクトのチームが分かれているところです。デザインシステムのチームがデザインシステムを作成し、彼・彼女らが作成したUIコンポーネントを企業内で配ります。そうすると、個別プロダクトチームのデザイナーやエンジニアはそれらのUIコンポーネントをMergeに取り込んで各プロダクト用のプロトタイプを迅速に作ることができます。それによってプロダクト開発の速度を上げるだけでなく、同じ企業としてのデザインの一貫性を保つことができます。UXPin社はこの一貫性を大事に考えており、Mergeは「A Single Source of Truth」をモットに開発されたと言われました。

2回に跨ぐレクチャー、試用とその前後の議論を通して、UXPin社の方々にも話しましたけど、まだデザインシステムがそれほど広く浸透しておらず、デザインシステムを活用した社内でのデザイン展開の事例も少ない日本では使えるシーンが(まだ)限られるかと思いますが、一部の大手企業、あるいは先進的な技術スタートアップには有効なソリューションだと思われます。UXPin社の方々も日本マーケットへの展開に力を入れており、近々良い事例も出てくるのではないかと思われます。弊社も今回の試用で得た知識と経験を元に、UXPinやMergeの活躍が期待できる案件を見つけ、実導入と活用を行ってみたいと思っております。

以下は、弊社のデザイナー兼エンジニアであり、Mergeのテストを主に担当したJacoboのMergeに関する記事です。(英語ですが(汗))より詳しい情報を知りたい方はお読みください。

Trying out UXPin’s Merge and its Storybook integration

Introduction

A couple of months ago, I had the opportunity to try out UXPin with a trial that they provided for us to specifically test the new functions of Merge. In the following article, I will share some of my own impressions and thoughts on what could be the next steps to facilitate collaboration between designers and programmers.

If you go back to my previous posts, you can see I’m on a threshold between designer and programmer. Job and education titles apart, my daily work routine consists of finding logical solutions to processes inside an application and then writing them in code. The designer part comes when the user’s perspective is considered, then some changes may occur in order to improve the experience. This involves more than defining visual aesthetics, it requires considering how the application’s interface would be subtle enough for someone to not notice it and can focus on what they are trying to achieve.

I struggle sometimes with the back and forth between iterations of coding when it’s related to fixing the user experience. One thing is needing to adjust what you made because you get errors in your console, but a different issue comes when objectively your program is working, and then you have a user that feels something is not right about it. Sure, the whole design rules, good practices, and lots of theories can be applied, but your client probably won’t take it so well if you confront them with theory textbooks when they are asking you to make changes. Here is where Design Systems can help: you have already tested and working components that you can use as blocks to build up new applications without thinking too much about every single detail inside them.

UXPin Merge aims to bring Design Systems to the design prototyping phase of a project, by connecting ready-made components from a Design System with UI/UX prototyping tools. In this way, the designers would be able to use actual coded parts to allow for fast prototyping. UXPin Merge’s motto is “A single source of truth” since what you see in the prototype is combining design with actual working code.

UXPin and the step from designing to coding

Let’s start with just UXPin. Essentially, UXPin is a UI/UX design tool similar to Sketch, AdobeXD, or Figma, and it inherits some of these applications’ core concepts by following conventions that enable its users to adapt easily. You can create the parts of a UI from primitive shapes; you can also change their color, border, and other visual details. There is also a feature that enables you to build mock-ups with basic interactions (this is also similar to other products).

UXPin has a quite familiar UI

In all of these applications, there is a big step from what the designer makes on the design tool and what happens on the repository where the real working product gets coded. Tools like the inspect tab inside Figma enable you to see roughly how the CSS behind a certain object would look like. However, this is not always an accurate connection between what is designed and what is coded.

Designers and programmers essentially come from two different worlds, at least as far as the tools they use in their daily work. Trying to find a commonplace between these can lead to interminable meetings and messages scattered through all sorts of communication tools. This might be the very issue that UXPin Merge aims to solve, by having “A single source of truth” that all of the team can reference.

The UXPin Merge approach

UXPin Merge works as a sort of extension of UXPin. Essentially what Merge does is bringing Design Systems to UXPin. Hence, the designer can use real components in their mock-ups. These are already coded in the Design System repository, and the designer can access its different variations inside UXPin as needed. This way, the integrity of each component is never compromised. It takes away liberties from the designer, but you could argue that Design Systems are meant to do this.

UXPin Merge actually lives inside this Library container

Once you have a Design System ready to go, you won’t really be modifying it as often. Someone that wants to develop with a Design System must respect its set of rules so the final product looks as intended and they can have the advantages for a rapidly developing process. Of course, some Design Systems give more liberties than others, but in a sense what they do is put restrictions. Likewise, UXPin Merge heavily limits the designer, they can no longer change a component as easily, and if needed they would have to talk with the programmers to update the code.

Once imported, you can have a component with all its variations. In this case, you can change the Type, Size, Disabled, Label, Click properties of a Button which are defined in the props of the React Component.

These limitations are actually meant to facilitate the work of the designer. They are receiving ready-made pieces that they can use to build the most crucial part: the user experience. Sure, color, padding, fonts, and other visual elements are important parts of the experience, but choosing every little single detail can slow down the process, and if all of that is already sorted out in the Design System, it can be very easy for designers to get to work on mock-ups with the real coded components. Additionally, if these change in code at some point, they will also get updated within any mock-up that is using them.

Connecting with Storybook

Another feature of UXPin Merge I got to see was their connection with Storybook. Storybook serves as a sort of Design Systems repository used by many companies, and very flexible as it can hold components made in different frameworks. Now, setting up a Storybook project and placing all the components of a Design System is quite a lengthy task, and programmer-less teams might have a hard time, but once you have it ready, it holds and displays your Design System neatly.

UXPin Merge aims to bring what is defined in Storybook to UXPin so components made in whichever framework can be used to make UI/UX mock-ups. The integration part is very simple, in theory with only the URL of a published Storybook project, you can grab its components to use for your mockup. The moment I saw it, it seemed to work perfectly with React components.

Thoughts for the future

Attempting to organize the design process that UXPin Merge aspires to have, can be seen as follows:

UXPin Merge focuses on Step B since it provides ready-made real coded components that you can use to iterate faster when designing mock-ups. However there is some loose ground in Step A and Step C. With a defined Design System you really shouldn’t worry about Step A because it is supposed to be immutable, still, there is a possibility that you need to adjust something on the coded components, especially if you are still in the middle of developing your Design System.

The same with Step C, which is the whole build-up of the application. Of course, we can copy the components from the Design System repository and look at the mock-up to see how they are assembled together. But there is not yet an improvement for going back and forth between design and coding.

UXPin Merge aims to fulfill some of these barriers, and it seems to be a great solution for being able to do rapid prototyping with ready-made components that come from already made Design Systems. However, it appears that certain steps are still to be covered. Also, there’s a sense that designers are on the losing end of this as they lose some power in favor of employing ready-made components. There might be other ways to bring the two parties together.

この記事を書いた人

モレノ キロガ ハコボ エンジニア / デザイナー

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

Contact

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

arrow

Careers

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

arrow

Copyright© Fixel Inc. All rights reserved.