I transitioned from a frontend developer to a UX designer at Infor

 

  • UX designer in an agile environment, in a small team of two.

  • I was mostly responsible for the how and why of the design in form of interaction design and user experience design. I mostly focused on ideation, sketching, and wireframing.

  • Designed mockups and prototypes that were delivered to development.

  • Worked with a design system for creating a great and consistent product experience.

  • Direct feedback with product management and developers.

A Design System

As a developer years prior to becoming a UX designer, I worked with implementing the Design System in code, creating a UI library, and styling standards for frontend developers. We developed something that we named "Themes," and the Design System was based on the "Base Theme." The theme could be managed in Sketch but usually by duplicating the master file and then changing palettes, typography, etc.

As a designer I worked on changing our colors in the Design System to become WCAG 2.0 Level III compliant. In addition, I also further defined the color system to make it more specific. The colors are dynamically defined and are not set to one particular color but a function in the product. There are also some instructions to ensure that designers use colors appropriately to ensure that they are WCAG 2.0 Level III compliant.

A Design System - Colors Example

  • A display of colors showing the different variations of the Base Color.

    Base Color

    The Base Color is used for text and information essential elements; it needs to use a clear set of colors for background, text, and content separation.

    The Base Color was set to a color that can pass a WCAG AAA background and foreground combination as well as possible. The example shown here has 9/10 color coverage. Even if the customer does not need to cover WCAG A, AA, AAA, or Section 508, it is important to include all kinds of users; despite having disabilities. Examples where the base color is used:

    • Text (headings and copy),
    • Dividers (content dividers, table borders, list dividers),
    • Input fields (input text, background, border),
    • Dropdowns, (input text, text, background, border)
    • Search

  • Color Schema

    The color schema represent a set colors that are function based. The color schemas are split into different areas of usage. In each area of usage the schema is split into three different elements. These elements are:

    • Main Element is the default color for your main color schema elements. The main element is the most occuring color element.

    • Interaction element displays user interaction with a UI element. The interaction element color is a dark version of the main element.

    • Highlight element is the color element that is used for highlighting the background for things such as active or important elements.

    The color schema consists of primary color, secondary color, and accent colors from one to three. Primary and secondary color displays the most prioritised actions in the UI. As an example, the primary color represents fulfilling an action, and the secondary color represents canceling an ongoing action..

    There are three accent colors available. These are not all in use but are available to create the needed variation for customers with broader color palette needs.

  • Status Colors

    The status colors consist of four different colors to represents different events in the UI. Alerts to give notice to users, success represents actions that are successful, warning informs users to be cautious about their actions, and errors informs the users of system based errors.

Rhythm UI Kit examples

  • Image of typography from Rhythm UI Kit

    Typography

  • Image of typography example from Rhythm UI Kit

    Typography example

  • Image of buttons from Rhythm UI Kit

    Buttons

  • Image of Links from Rhythm UI Kit

    Links

  • Image of Input Fields from Rhythm UI Kit

    Input Fields

  • Image of Data Table example from Rhythm UI Kit

    Data Table example

A Rhythm for Commerce Component

Order Approval - Order Checkout & Order History Changes

Product Management initiated this project as it was a function that existing customers needed. There was an existing Order Checkout and Order History component in the Rhythm for Commerce product. The design work here was to identify the flow that Order Approval required and the different components in the system that needed design changes.

I sketched out the Order Checkout and Order Approval flow, and in this work, I did not do any wireframes as there were just adjustments that were done to different elements in the commerce components.

A diagram was created and then reviewed by developers and product management to assess the different components that needed updates. After the flow was approved, I made changes to the affected commerce components.

Order Approval - A Commerce Component Example

Sketching, discussing and reviewing how the order approval flow will work and what components (widgets) will be affected

The new order checkout flow, including the order approval process.

Changes made to the checkout process. Step 3 only had payment as option before, now it has review as an option.

Previous

Billink for Fragus Group - Under Construction
Next

Infor Employment - Frontend Developer