Low code Integration Platform as a Service (IPaaS)

Keep narrowing with design definition

Feature specs documation in Figma

When we had enough information to start documenting our feature I consolidated the information in a Figma file, providing access to all stakeholders. The file included the ideal user journey wireframes, but also information around empty state, partial state, loading state, error state, technical consideration, story # in Jira and stakeholders involved in building the feature.

Wireflows & Low-fi prototype

Alongside the feature specs documentation I kicked off wireflowing activities. When it comes to early design definition, I always try to combine wireframes, user flows, and low-fi prototypes to create visual user flows that can be easily shared and discussed. At this stage, I start adding more detailed information about which UI elements will be displayed. The design remains rough to keep the focus on the flow. This is a great tool for starting to inventory components.

Low-fi prototype in order to create VISUAL user flows that can easily be shared and discussed.

Behind-the-scenes of our low-fi prototype. When it comes to early design definition I always try to mix wireframes, user flows and low-fi prototype in order to create VISUAL user flows that can easily be shared and discussed.

Early concept testing and features validation

As the development of some features would cost months of work we decided to validate the features with users first. We gathered the participants we already interviewed and introduce them to the low-fi prototype. I had prepared some micro-interactions videos (using Protopie!) for the most complex parts of the product that we could not reflect in the prototype. We once again collected all the comments, organized the data, found themes and came up with insights.

Features prioritization aka "Doing the hard work to make it simple"

Product roadmap. After we prioritized the features we came up with the product roadmap and shared the product strategy and the road that we will be taking with everybody in the team.

When doing a first work estimation for each feature we quickly realized that we did not avoid a classic pitfall in project kick-off : we listed far too many features... We reviewed the list and kept the minimum acceptable and useful features to make our users happy and get enough engagement with our product. We prioritized features following the MosCow scale : Must have, Should have (needs further research & testing), Could have (to be addressed farther in the future), Won't have. After we prioritized the features we came up with the product roadmap and shared the product strategy and the road that we will be taking with everybody in the team.

UI Inventory / OOUX

The timeline allowed me to take time to run a component mapping. I took into consideration our final list of features and the information structure to come up with an UI inventory aka component mapping. I iterated in order to give this mapping more granularity by including metadata and content. At the highest level, OOUX allows us to see hoy objects relate to each other. I listed all the UI components, where and how they should be displayed so we were able to make better work estimations in terms of development.

Expanding the team

In the hiring process for designers with a strong front-end development focus for an IPaaS with such complex interactions, I prioritized finding talented coders first. Once I identified the right individuals, I crafted processes that allowed us to fully utilize their UX design strengths, by mitigating their weaknesses by myself or other individual, ensuring they could contribute as developers first so we could keep our focus on delivery but also as designers capable of solving design issues. This method helped balance technical expertise with creative problem-solving.

Development

Based on my previous experiences working with dev teams on complex products, I knew that as a designer I had to get involved and provide as much input as possible.

Design system using storybook based on UI inventory / OOUX

Development-oriented design system build with Storybook.

At this stage the main audience of the design system was the dev team so I created a Design System in Figma that would then be reflected, alongside with living components in Storybook via Chromatic. It followed a modular, "atomic" approach and offered dev ops reusable patterns. I designed the components and provide them to the team via Storybook. This way I would speed up the development process. As the team is growing next step will be to automate some parts of it and expande the scope to tolling, governance, accessibility, tech stacks, workflow and marketing.

Micro-interactions

Micro-interactions were created in Protopie and shared with dev team for validation.

This product is by far the most complex I had to work on in terms of interactions design. I designed them in Protopie and run a couple of alignment meetings with the dev team in order to validate what could be done. We have been iterating this way until we get the UI aligned with our expectations.

Continuous testing

We kept involving future clients and users in the loop so we made sure we were following the right path in terms of user needs. When we finally got a decent product to share, we conducted unmodarated and moderated usability studies (when we needed to dig into specific features details) so we could assess how easy it is for participants to complete core tasks in our product. The recorded sessions allowed us to provide some useful KPIs (Time on task, error rate, use of search bar). 8 participants was a must! As usual, thoughts and experience were captured, categorized and turned into insights and recommendations for stakeholders.

Final product and lessons learned