Design Language System Implementation in our iOS App
A lot of things have changed since our iOS app initial release. As described in https://medium.com/oyindonesia/evolving-oy-payment-feature-49aa8a150dcb, you might know that we are transform OY! from chatting to p2p payment application. To ensure consistencies in our design and experience, our design team took this opportunity to create our own Design Language System; Fortune. This Design Language System defines a blueprint that contains the set of design components (e.g. inputs, buttons, colors, fonts) that are allowed to be used in our existing and new screens in our app.
Challenge
Based on our DLS, we need to apply Fortune design philosophy in our iOS app project by creating new standard UIKit components and using them in multiple screens and scenarios. However, we had to do something to break it down and make it more manageable and reusable.
The challenge is to create UIKit components that could be shared between multiple projects.
Our Solution
We have decided to create an independent UIKit framework so that it could be shared between multiple projects. This approach allowed us to create reusable and modular UI Code.
Fortune framework contains our custom UIKit components like, views, controls, inputs, empty states, including fonts, icons, and other specific fortune’s assets.
Let us take a look at an example on how we break down our app screen into different components:
Above is a screenshot of a page where a user can connect their bank account. As you can see, it contains 5 UIKit components and each component is capable of rendering itself in different configurations.
For example, let us take a closer look at the second component. We call it FTInfoView which indicates an information in specific page. In our case, it has multiple configurations.
To create FTInfoView we use a horizontal UIStackView that contains icon, vertical UIStackView, and disclosure indicator on the right side, and the vertical UIStackView contains the two main labels. UIStackView makes us possible to create single UIKit component with multiple configurations.
Separating UIKit components into an independent framework means that we only need to code it once and we can reuse as many UIKit components as possible in multiple screens and scenarios out of the box.
Below are examples of other screens that reused the same UIKit components as above.
Tip: UIStackView is a great tool to create custom UIKit components to make the container view capable of rendering itself in different configurations
Lesson Learned
Decoupling UIKit components into framework will save time and reduce development cost. One of the nicest thing of having a separate UIKit framework is that we can create new specific project to play with it and to help the design team to validate new components.
For our rebranding process, we started with creating all of UIKit components first before modifying each screen. This will ensure that each individual engineer is not blocked by a particular UIKit component not being implemented yet. If you have single-digit team like us. You can start by creating the most widely used UIKit components in your app, like UITextField, UIButton, Avatar, etc. After that components are done then let half of your team start on changing each screen and let the rest of the team to keep creating custom UIKit components. This approach will make your design and QA team able to validate new screen early.
Also that being part of that process as early as possible will help your team to architect UIKit components better.
You might not think that programmers are artists, but programming is an extremely creative profession. It’s logic-based creativity. — John Romero
Want to experience the most seamless payment experience? Try to download OY! in Google Play and App Store and please feel free to give us feedback about it 👌🏼.
