Major overhaul
When I started the company was relatively small and without any design guidelines. I implemented a main
design system that all the platforms could use for their own native environment to make it work best for
their respective platform. My role as a designer was working with the different teams to bring in tested and
validated designs they could implement and gather feedback to further improve it.
Administration portal (webapp)
I started at Parakey as a freelance consultant to develop a design system that the dev team could use. The
admin portal (web app) was filled with conflicting user patterns that made it very hard to use. No clear
button hierarchy, a large number of text styles, multiple hues of the same blue, failing color contrast
checks, and multiple primary users. This web app was built bit by bit without any over-arching thought of
its wholeness which resulted in a bloated component library.
The product had its flaws in the UX and UI so I began stripping down the essentials and setting up the design
system. I began by generating different hues of the same color and began mapping out the colors to find out
what was being used and what could be redundant. From there I began naming the colors after their use
instead of “primary-blue-100”, this makes it easier to create different stylesheets moving forward, such as
a dark mode and high contrast mode.
This administrative tool displays a lot of information so text styles were important so the sizes could not
be too small, the amount of styles did not need to grow substantially but the layout and patterns had to be
improved to make the information more legible and relevant within it’s context.
Another issue that needed to be resolved was the number of buttons, in the example above there is no clear
indication of what is a primary button. The same styling is used for a badge/icon as well as a button. Hark!
There is an orange button too, after I conducted some interviews there was hesitation among users if this
was a destructive action or not. So I documented all the buttons and contexts to establish what each primary
action was expected in such context to create a hierarchy, and from there, the guidelines were established.
The design system was created and the first steps were taken to implement it, from there I created
components required for the first iteration and constantly required re-evaluations and updates based on new
feedback and new features.
iOS and Android
The phone apps for iOS and Android contained a lot of custom components that were not native to their
respective platform. This was a symptom of creating a app with multiple primary users groups.
In the beginning there was only one app developer who also was a recent hire, it might sound drastic but
with only us two we really had to optimise our workflow without compromising the quality of the product.
By using native components the design had clear limitations but established patterns documented in the Apple
Human Design Guidelines. The Android platform does not have as much native components, even though the
Android Material Design guidelines documents how a Android app should be they are contradictory and every
Android phone manufacturer has their own own patterns. So we opted to use the iOS guidelines as a precursor
for both platforms.
At first, the design was very limited since we had to support very old versions but since we used native
design components the OS version bumps gave us so many design updates without the need to create them from
scratch.
By using the native design components we were able to eliminate conflicting patterns such as a cell that has
an action and a navigation, cells that had multiple actions, and buttons that lacked the necessary
press-area. As well as redundant information, conflicting action types, models that were unnecessary as well
as features that should have run in the background but did not. We even made dark mode available by just
mapping out the colors.
This app was marketed towards a general end-user, the app was not outfitted with the necessary features to
make it more user-inclusive. When we ditched the custom work and went over to native components we could
piggyback on the system settings and increase the contrast as well as character size as a default based on
the user’s preference.