Transformed the Market's Leading PPM Platform, as Lead UX Designer
Transformed the Market's Leading PPM Platform, as Lead UX Designer
Transformed the Market's Leading PPM Platform, as Lead UX Designer
Organization:
Sensei Labs
App:
Conductor
Timeframe:
・2023–current (contract)
・2021–2023 (full-time)
My role:
Lead UX Designer (FT), UX Consultant
Tools:
Figma, Aha!, Pendo
Organization:
Sensei Labs
App:
Conductor
Timeframe:
・2023–current (contract)
・2021–2023 (full-time)
My role:
Lead UX Designer (FT), UX Consultant
Tools:
Figma, Aha!, Pendo
Organization:
Sensei Labs
App:
Conductor
Timeframe:
・2023–current (contract)
・2021–2023 (full-time)
My role:
Lead UX Designer (FT),
UX Consultant
Tools:
Figma, Aha!, Pendo
Industry
Enterprise Software
Headquarters
Toronto
Founded
2015
Company size
80-100
I joined in 2021, got promoted to Lead Designer in 2022, and transitioned from full-time to contract work in 2023.
I led end-to-end design. The main challenge was integrating diverse features into a single cohesive system. I was able to ship faster after building the design system, improve user satisfaction, and help acquire clients from our new features.
2x
more features shipped
(compared to previous year)
10%
fewer support tickets (from customer support portal)
Industry
Enterprise Software
Headquarters
Toronto
Founded
2015
Company size
80-100
I joined in 2021, got promoted to Lead Designer in 2022, and transitioned from full-time to contract work in 2023.
I led end-to-end design. The main challenge was integrating diverse features into a single cohesive system. I was able to ship faster after building the design system, improve user satisfaction, and help acquire clients from our new features.
2x
more features shipped
(compared to previous year)
10%
fewer support tickets (from customer support portal)
Industry
Enterprise Software
Headquarters
Toronto
Founded
2015
Company size
80-100
I joined in 2021, got promoted to Lead Designer in 2022, and transitioned from full-time to contract work in 2023.
I led end-to-end design. The main challenge was integrating diverse features into a single cohesive system. I was able to ship faster after building the design system, improve user satisfaction, and help acquire clients from our new features.
2x
more features shipped
(compared to previous year)
10%
fewer support tickets (from customer support portal)
The design process
UX research
The designs always followed research, and I always came back to what the customer feedback indicated before making design decisions.
User research
The design team ran cross-functional workshops to synthesize what we knew about our users. Then we made user personas and journey maps for preliminary user flows.
These were a decent starting point in the early days; but gradually they felt less relevant (and too generic) when designing specific features. I gradually began empathizing through functionality-scoped proto-personas instead. For example:
Project Leads tended to think Conductor was annoying because they would log in once/month simply to update their KPI's
Directors tended to love Conductor because they could see all the data rolled up, enabling them to make decisions more easily
Ongoing customer feedback
Throughout the process, I gathered feedback by:
Tracking in-app behavior (e.g., clicks and time-on-page, via Pendo)
Tracking support tickets from our customer request portal (via Zendesk)
Reviewing client feedback videos in bi-weekly internal meetings (via Gong)
Attending monthly “product advisory council” meetings with clients, where we discussed roadmaps, asked about user needs, and showed design prototypes
Evolving the process to rapid prototyping
Building our design system (DS) was a major undertaking; but by fleshing it out and constantly maintaining it, I eventually had effectively reduced the need for low-fidelity wireframes, aside from when building new features from scratch.
I was able to leverage the DS to rapidly prototype new user flows in high fidelity.
End-to-end design
In addition to the Figma designs, I owned virtually all of the products/features I built, which entailed supporting engineering through development and ensuring their implementations met my acceptance criteria, passed testing, etc.
The design process
UX research
The designs always followed research, and I always came back to what the customer feedback indicated before making design decisions.
User research
The design team ran cross-functional workshops to synthesize what we knew about our users. Then we made user personas and journey maps for preliminary user flows.
These were a decent starting point in the early days; but gradually they felt less relevant (and too generic) when designing specific features. I gradually began empathizing through functionality-scoped proto-personas instead. For example:
Project Leads tended to think Conductor was annoying because they would log in once/month simply to update their KPI's
Directors tended to love Conductor because they could see all the data rolled up, enabling them to make decisions more easily
Ongoing customer feedback
Throughout the process, I gathered feedback by:
Tracking in-app behavior (e.g., clicks and time-on-page, via Pendo)
Tracking support tickets from our customer request portal (via Zendesk)
Reviewing client feedback videos in bi-weekly internal meetings (via Gong)
Attending monthly “product advisory council” meetings with clients, where we discussed roadmaps, asked about user needs, and showed design prototypes
Evolving the process to rapid prototyping
Building our design system (DS) was a major undertaking; but by fleshing it out and constantly maintaining it, I eventually had effectively reduced the need for low-fidelity wireframes, aside from when building new features from scratch.
I was able to leverage the DS to rapidly prototype new user flows in high fidelity.
End-to-end design
In addition to the Figma designs, I owned virtually all of the products/features I built, which entailed supporting engineering through development and ensuring their implementations met my acceptance criteria, passed testing, etc.
The design process
UX research
The designs always followed research, and I always came back to what the customer feedback indicated before making design decisions.
User research
The design team ran cross-functional workshops to synthesize what we knew about our users. Then we made user personas and journey maps for preliminary user flows.
These were a decent starting point in the early days; but gradually they felt less relevant (and too generic) when designing specific features. I gradually began empathizing through functionality-scoped proto-personas instead. For example:
Project Leads tended to think Conductor was annoying because they would log in once/month simply to update their KPI's
Directors tended to love Conductor because they could see all the data rolled up, enabling them to make decisions more easily
Ongoing customer feedback
Throughout the process, I gathered feedback by:
Tracking in-app behavior (e.g., clicks and time-on-page, via Pendo)
Tracking support tickets from our customer request portal (via Zendesk)
Reviewing client feedback videos in bi-weekly internal meetings (via Gong)
Attending monthly “product advisory council” meetings with clients, where we discussed roadmaps, asked about user needs, and showed design prototypes
Evolving the process to rapid prototyping
Building our design system (DS) was a major undertaking; but by fleshing it out and constantly maintaining it, I eventually had effectively reduced the need for low-fidelity wireframes, aside from when building new features from scratch.
I was able to leverage the DS to rapidly prototype new user flows in high fidelity.
End-to-end design
In addition to the Figma designs, I owned virtually all of the products/features I built, which entailed supporting engineering through development and ensuring their implementations met my acceptance criteria, passed testing, etc.
UX/UI design
The initial challenge: Parts of an integrated whole
The challenge (and strength) of Conductor is that many of its parts feel large enough to be their own app, but all new features must integrate into one cohesive system. This makes it flexible enough to accommodate a variety of user types and organizational preferences.
For example, someone can create a task on the “Project” page, update status on “Board,” change the deadline on “Timeline,” and assign it on “Team.” Other users prefer to do it all on the “Task” page.
So before I conceptualized new features based on user research, I started improving our core features. Here's a small sample of them (click to enlarge):
Project KPIs (for data entry)
Timeline (Gantt chart)
Board (Kanban)
Maestro feature
(automated warning system)
Browse menu with custom tags
(for custom navigation)
KPI explorer
(data inspection tool)
UX/UI design
The initial challenge: Parts of an integrated whole
The challenge (and strength) of Conductor is that many of its parts feel large enough to be their own app, but all new features must integrate into one cohesive system. This makes it flexible enough to accommodate a variety of user types and organizational preferences.
For example, someone can create a task on the “Project” page, update status on “Board,” change the deadline on “Timeline,” and assign it on “Team.” Other users prefer to do it all on the “Task” page.
So before I conceptualized new features based on user research, I started improving our core features. Here's a small sample of them (click to enlarge):
Project KPIs (for data entry)
Timeline (Gantt chart)
Board (Kanban)
Maestro feature
(automated warning system)
Browse menu with custom tags
(for custom navigation)
KPI explorer
(data inspection tool)
UX/UI design
The initial challenge: Parts of an integrated whole
The challenge (and strength) of Conductor is that many of its parts feel large enough to be their own app, but all new features must integrate into one cohesive system. This makes it flexible enough to accommodate a variety of user types and organizational preferences.
For example, someone can create a task on the “Project” page, update status on “Board,” change the deadline on “Timeline,” and assign it on “Team.” Other users prefer to do it all on the “Task” page.
So before I conceptualized new features based on user research, I started improving our core features. Here's a small sample of them (click to enlarge):
Project KPIs (for data entry)
Timeline (Gantt chart)
Board (Kanban)
Maestro feature
(automated warning system)
Browse menu with custom tags
(for custom navigation)
KPI explorer
(data inspection tool)
Iterations from feedback
Many of my projects were responses to user feedback. Here are three of the more visually-evident redesigns, with key improvements summarized for each.
Task Page (modal dialog)
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Timeline (Gantt chart)
I improved the Timeline by simplifying both the look and functionality of the bars.
Email notifications
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Iterations from feedback
Many of my projects were responses to user feedback. Here are three of the more visually-evident redesigns, with key improvements summarized for each.
Task Page (modal dialog)
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Timeline (Gantt chart)
I improved the Timeline by simplifying both the look and functionality of the bars.
Email notifications
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Iterations from feedback
Many of my projects were responses to user feedback. Here are three of the more visually-evident redesigns, with key improvements summarized for each.
Task Page (modal dialog)
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Timeline (Gantt chart)
I improved the Timeline by simplifying both the look and functionality of the bars.
Email notifications
I improved the visual hierarchy and used progressive disclosure to make the UI more intuitive, and guide users without overwhelming them.
Solving both business + user needs
In addition to building our design system and new features, I led several large design projects such as the overhaul of our notifications system (mainly focused on email). This entailed analyzing thousands of notifications sent to users over three months, and identifying patterns and problems.
This research led to the “email builder” solution, saving dozens of hours each month for our support team, by off-loading personalization onto the users (rather than manually fulfilling customer support requests).
Snapshot of notifications dataset with 3000+ rows of data (colorized for readability)
This was a win-win, as users also prefer a self-service UX.
Weekly Progress Report (email template)
Weekly Activity Summary (as seen in Outlook)
Solving both business + user needs
In addition to building our design system and new features, I led several large design projects such as the overhaul of our notifications system (mainly focused on email). This entailed analyzing thousands of notifications sent to users over three months, and identifying patterns and problems.
This research led to the “email builder” solution, saving dozens of hours each month for our support team, by off-loading personalization onto the users (rather than manually fulfilling customer support requests).
Snapshot of notifications dataset with 3000+ rows of data (colorized for readability)
This was a win-win, as users also prefer a self-service UX.
Weekly Progress Report (email template)
Weekly Activity Summary (as seen in Outlook)
Solving both business + user needs
In addition to building our design system and new features, I led several large design projects such as the overhaul of our notifications system (mainly focused on email). This entailed analyzing thousands of notifications sent to users over three months, and identifying patterns and problems.
This research led to the “email builder” solution, saving dozens of hours each month for our support team, by off-loading personalization onto the users (rather than manually fulfilling customer support requests).
Snapshot of notifications dataset with 3000+ rows of data (colorized for readability)
This was a win-win, as users also prefer a self-service UX.
Weekly Progress Report (email template)
Weekly Activity Summary (as seen in Outlook)
Beyond UI design
In order to help my colleagues outside the design team (customer success, marketing, development, etc.) I occasionally did design work or writing outside of the scope of UI design, including:
posters/graphics for customer education
company wiki articles, for knowledge management
content guidelines for common problematic in-app copy
help center articles (to model content guidelines & formatting)
designing PowerPoint decks for a few pitches with external stakeholders
Help center article (I wrote this article and made the diagrams for simplifications)
PowerPoint pitch deck (for a partnership)
Poster for a new feature (sent to users and prospects)
Beyond UI design
In order to help my colleagues outside the design team (customer success, marketing, development, etc.) I occasionally did design work or writing outside of the scope of UI design, including:
posters/graphics for customer education
company wiki articles, for knowledge management
content guidelines for common problematic in-app copy
help center articles (to model content guidelines & formatting)
designing PowerPoint decks for a few pitches with external stakeholders
Help center article (I wrote this article and made the diagrams for simplifications)
PowerPoint pitch deck (for a partnership)
Poster for a new feature (sent to users and prospects)
Beyond UI design
In order to help my colleagues outside the design team (customer success, marketing, development, etc.) I occasionally did design work or writing outside of the scope of UI design, including:
posters/graphics for customer education
company wiki articles, for knowledge management
content guidelines for common problematic in-app copy
help center articles (to model content guidelines & formatting)
designing PowerPoint decks for a few pitches with external stakeholders
Help center article (I wrote this article and made the diagrams for simplifications)
PowerPoint pitch deck (for a partnership)
Poster for a new feature (sent to users and prospects)
Key takeaways
Culture can significantly influence workflows: Early on, our culture was highly bureaucratic, with excessive meetings and guardrails to mitigate risk. While this had its benefits, it slowed down my work. When leadership identified the bottlenecks, alongside a large cultural change — ie. switching to a 4-day workweek — the red tape was significantly lessened, and my work became much more efficient.
With great flexibility comes great responsibility: When you give people the freedom to customize, they feel empowered... but they may also unwittingly degrade the UX. For example, by changing their UI to red, one client had made all the warnings (red, to grab attention) harder to notice. After I joined, we shifted our “customize everything” mindset to more of a “personalize most things” mindset, being more opinionated with how users should get the most out of Conductor.
Managing design systems is brutal (but necessary): For large products like Conductor, it would have been impossible to maintain a consistent UX without a design system. It also sped things up once it was up in running… but building and maintaining it is a massive time investment. I learnt that it’s mostly unappreciated by non-designers, because most people simply have no visibility/understanding of its utility.
Key takeaways
Culture can significantly influence workflows: Early on, our culture was highly bureaucratic, with excessive meetings and guardrails to mitigate risk. While this had its benefits, it slowed down my work. When leadership identified the bottlenecks, alongside a large cultural change — ie. switching to a 4-day workweek — the red tape was significantly lessened, and my work became much more efficient.
With great flexibility comes great responsibility: When you give people the freedom to customize, they feel empowered... but they may also unwittingly degrade the UX. For example, by changing their UI to red, one client had made all the warnings (red, to grab attention) harder to notice. After I joined, we shifted our “customize everything” mindset to more of a “personalize most things” mindset, being more opinionated with how users should get the most out of Conductor.
Managing design systems is brutal (but necessary): For large products like Conductor, it would have been impossible to maintain a consistent UX without a design system. It also sped things up once it was up in running… but building and maintaining it is a massive time investment. I learnt that it’s mostly unappreciated by non-designers, because most people simply have no visibility/understanding of its utility.
Key takeaways
Culture can significantly influence workflows: Early on, our culture was highly bureaucratic, with excessive meetings and guardrails to mitigate risk. While this had its benefits, it slowed down my work. When leadership identified the bottlenecks, alongside a large cultural change — ie. switching to a 4-day workweek — the red tape was significantly lessened, and my work became much more efficient.
With great flexibility comes great responsibility: When you give people the freedom to customize, they feel empowered... but they may also unwittingly degrade the UX. For example, by changing their UI to red, one client had made all the warnings (red, to grab attention) harder to notice. After I joined, we shifted our “customize everything” mindset to more of a “personalize most things” mindset, being more opinionated with how users should get the most out of Conductor.
Managing design systems is brutal (but necessary): For large products like Conductor, it would have been impossible to maintain a consistent UX without a design system. It also sped things up once it was up in running… but building and maintaining it is a massive time investment. I learnt that it’s mostly unappreciated by non-designers, because most people simply have no visibility/understanding of its utility.
