My Role
Sr. Product Designer

Introduction

Just as important to design, is the design process. This document will walk you through a real case study I had working with the Rogers Design Team. Sure, I could show you designs we outputted from the team to our system, but there’s more to making things pretty and usable on the site. Process is just as important for clear, effective, level-set delivery.

Overview

When joining Rogers, I initially started as a UI designer, working primarily within the learn ecosystem. Basically, everything related to first-level pages on Rogers and Fido.com pages. I got a really good lay of the land, but constantly was met with barriers on intaking, onboarding, and delivery of components.

At this time, Rogers had a well-established (albeit a disconnected) design system. We were about 18 months into release of the first pieces of the design system. The adoption to the design system was quite low, limited only to a few number of teams. It led to disjointed experiences depending on which app and team was doing what. Ultimately, the goal of the design system was clear, and should answer all these pain points. We have so many different teams, applications, roles and responsibilities. It’s a lot to navigate.

But I still saw first hand the limitations, the long timelines and knew there must be an easier way. I went to the source - our design system team. I engrained myself in their work even if I wasn’t formally part of their team. Eventually, I just flat out asked them for a role. They were happy to have me join the team, and gave me the freedom and flexibility to try and improve our existing processes. So I got to work.

Foundation Review

I started by going back to a team-wide survey given to all designers within the Rogers Digital team (heck, I even participated in this survey). I review their problems other teams encountered, other roles, all their comments, pain-points and successes of the team, to get a high-level understanding of what was working and what wasn’t working. I came to three foundational problems within the team.

1. Discovery:

   Designers and Product owners don’t know which components are available to them, or which components can be used for their specific line of business needs.

2. Communication

   There’s no method for alerting people when new components are added or existing components are enhanced so changes get logged as bugs from these teams. Updates are only announced via Slack, which can be easily missed and not available to all stakeholders

3. Feedback

   There’s no system for reporting bugs, or requesting new features. It’s all very arbitrary and through back channels, leading to lots of communication gaps, increased timelines, missed opportunities, and unclear problem statements.

Feedback is huge. This seems to be a major issue amongst the team. Before we can even start to review these other issues, this needs to be addressed. With no clear expectations from the team, and how we work, who does what and who doesn’t, our team started by defining what we call “Our Guiding Principles”. These are what we get buy-in from our partners on how we will deliver.

Unified Over Same

Create a unified and cohesive experiences that are meaningful from a user’s perspective, and not create the ‘same’ experiences because it’s quicker and easier to build.

Appropriate over Right

Our measure of quality of a solution is it’s appropriateness in the given context — not how perfect or fast it can be delivered.

Trust over Contest

We trust and respect each other’s talents and abilities. We neither tell the other person how to do their job, nor second guess their decision in their field of expertise.

Momentum over everything else

We work in harmony to ship sprint over sprint. We are open to improving delivery and process, and will maintain an adaptable approach to all aspects of our output.

Once we’ve established our team’s guiding principles, we started to work on ways to improve our processes. It has been a labour of love, and we’ve learned so much about all of our teams, our members, and how different the ways our teams work. This process has been shaped and has been constantly evolving. After a few months, our process has stayed relatively the same, but we are one of the few teams within the Rogers digital space that is truly agile, collaborating sprint over sprint between dev and design working in tandem to produce high quality and flexible components into our Design System.

Here’s a good look at our process now

Design Process Workflow

I’ll spend some time breaking down each one of these refined touchpoints, and explain the value each one of these brings to ensure consistency, ensuring all our work is vetted and reviewed, and ultimately that they are successful in their scope and delivery.

A Welcomed Request and Feedback Form

At this stage, we had no real way for someone to communicate their needs in any sort of trackable way. Sure, we had Jira for creating tickets, but expectations were never clear. Language between teams was never the same. It made for many unclear stories and slow back and forth between teams. Meetings after meetings, just spinning our wheels. There could be a better way.

We started by creating a new feedback system within Confluence. Everyone could write a small introduction of their request, title it, give us an idea of what it was. This creates a cascading ticket into a new Jira board (called our intake board). We have a new way to track requests coming into the system. Open, under-review, blocked, rejected, and approved. Clarity given to designers, and clarity given to the requesting product owners. Before submission of this feedback, we still had a problem with clarity. So we introduced the pitch document. Our contract among our team. Our working document. Our saviour.

What’s your Pitch?

This was a foundational problem within our delivery. What do we actually want? What work has been done? Who is deciding the value on anything being taken into the system? What other considerations need to be made that one singular person can’t answer? Who can say yes, and who can say no? Where does accessibility come into all this?

A pitch answers all these questions. So, what is a pitch?

Much like a sales opportunity, a pitch answers many fundamental questions, but ultimately it’s just that - a pitch. Tell me what you need, and why you need it. Answer some basic questions, and make a space for others considerations. We strive to answer these questions in a pitch:

1. What is the problem statement? How does this impact our users and what does a user want?

2. What is your appetite for this work? (scope)

3. What research have you done? Have you done any competitive analysis? Have you spoken to our users? Have you review our analytics to determine what this problem is that we are solving?

4. What is your proposed solution?

5. What is your visual representation of this solution?

6. How does this work from our largest to smallest breakpoint?

7. What accessibility requirements do we need to make as they align with your solution?

8. What are the things you don’t know?

9. What are things that are entirely out of scope for this project (our no-gos)?

Of course, we do not expect the submission owner to be able to answer all of these questions. That’s what the process is for. We need to refine this pitch. But how do we even get this pitch to the right people?

Our Working Group

Transparency has always been a problem — one hand not talking to the other. We have many different design teams, different products, different lines of businesses, heck — even different brands (Rogers / Fido / Chatr and Rogers for Business). It’s hard to ensure that one teams needs are being met, while another teams needs aren’t. We lacked that over-arching vision between teams, as shown with our team survey. How can we improve this process? Enter the DSWG (Design System Working Group).

The DSWG is a weekly meeting getting all the lead designers from all our different teams, and application, each bringing their own unique skillset and knowledge. We have representation from Design Systems (myself), development, the learn environment, ecommerce, self-serve, and a plethora of cross-team, and cross-brand experts. We take one-hour of our time every week to go over anything that has come through the feedback form. If a team with no representation submits something, we invite them to join as well. We set a clear agenda, take minutes, and mark decisions. We evaluate each and everything being contributed to the design system. Each ticket and pitch submitted into the form is vetted and expanded on.

Do we see value in this component being used elsewhere beyond this one use case? Why is this the best solution? What other considerations should we make? We answer everything. Unified over same. We update the pitch with all our notes, and fill in any gaps. If we can’t solve it in one session, we set a Design Jam. Everyone gets together, brings their use cases, audits internal pages, does competitive analysis, and designs a solution together in real time. Once this is done and if approved, our next stop is our Design Council.

Our Council

The Design Council is a group of experts within the organization. We have user research, our creative lead, our accessibility guru, our lead developer, and our UX/IA expert. They review the updated pitch and check for any considerations that haven’t been made yet. Appropriate over right. If anything is missing, they are sending it back to the Working Group, or back to the submission owner. These first three phases are very collaborative, often with small back-and-forth question sessions to ensure we are level set.

Once everything has been vetted, we now get everyone together, and come to an agreement.

The Shape-up

At this point, our pitch is almost entirely filled out. But through previous discussions, we want to make sure nothing was missed. We added this meeting to happen up to 3 times per sprint, for one hour sessions. That means with our limited design system team, we can handle intaking up to three requests for delivery every sprint. In this meeting we have:

• The requesting Product Owner

• The original requesting Designer

• The Design System Product Owner

• The Design System Designer (myself)

• Application dependent developers

• Design System Developer

• QA

• Accessibility

• Content

• Any other secondary/tertiary partners

We go through each step of the pitch one at a time, to ensure the solution is viable and necessary. We document any concerns, change scope if needed, and update the pitch. We mark attendance and this becomes a contract between teams - this is what we are delivering. Everyone has a voice here. Trust over Contest. If anything changes after this session, it’s considered out of scope can be taken on as an enhancement in the future. We do not want to have. to go back and evaluate again. Momentum over everything.

At the end of this session, we are able to begin our work in an agile delivery.

Let’s Get to work

During covid and going full remote isn’t without it’s communication issues. We’ve constantly been striving to ensure we’re communicating clearly. Thankfully, our process has stood up to covid challenges, and our transparency (if anything) has improved. We’ve needed less face-to-face meetings, and more online chat has led people to review discussions at their own pace.

We create a dedicated team chat with everyone involved thus far. This is created every sprint, for every component that we are working to deliver. All documentation from both dev/design is updated and confirmed in real time. Any feedback is welcomed as we go, any unforeseen questions are asked and answered. We have meeting to demo code and confirm success and provide feedback. End of sprint is confirmed with delivery of all documentation from both parties. Stories within our sprint are moved to completed, and we begin our QA.

QA and Release

After our components have been completed, we have a team of QA evaluate for any discrepancies. During this time, minor tweaks might be made to either code or design, but nothing blocking. Accessibility is also reviewed, and we ensure. no new atoms are being used and nothing has gone rogue. It’s one final check for everything. Our code is deployed and our codebase is updated. Our components are now available to anyone who would like to use it - requestor or otherwise.

Evaluating our Success

Throughout this process, we’ve strived to maintain transparency, and welcome feedback. We are of the mind that everyone’s voice matters. If someone has an idea that can benefit all, speak up. We’re happy to remain flexible in our approach. But what are people saying about these changes?

We have many key players giving the processes rave reviews. Our processes are clearer, our deliveries are executed on time sprint-over-sprint, and we’re consistently bridging the gap between our different teams, products and lines of business. Design Systems are key in a digital space, and integral to our delivery timelines. In this market, especially in telecommunications, flexibility and speed are key. We need to be able to adapt.

Where do we go from here?

After refining our processes, it’s still important to go back, evaluate and close out any other gaps. Let’s review our previous survey, and see what else we could do to improve our delivery. We know there are three key pieces to address. We’ve taken feedback and run with it, but how do the other two align?

Discovery

Designers and Product owners don’t know which components are available to them, or which components can be used for their specific line of business needs.

How did we address it?

Yes, we have addressed it. By providing a more clear intake process, offering transparency amongst the teams (through DSWG and DC), designers and POs are now more engrained in the process. They have more visibility to our work.

What’s the future?

We have a goal to improve our find-ability in our ecosystem. Right now, our documentation is spread across Confluence, our Abstract+Sketch Library, and our Component Dev Kit. We are prioritizing a unified library and documentation page, with user priority given to all areas of the business.

Communication

There’s no method for alerting people when new components are added or existing components are enhanced so changes get logged as bugs from these teams. Updates are only announced via Slack, which can be easily missed and not available to all stakeholders

Did we address it?

Yes, DSWG and DC are integral to our process now, and we are more transparent. We’ve also started adding new monthly release notes via team, and documented in Confluence about any change (big or small) to any component. Our dedicated teams channels during B+I offer greater transparency, as well as all our other ceremonies. Nobody is left out.

What’s the future?

Creating a centralized documentation repo would solve many issues around communication. This will only get better in 2021.

Feedback

There’s no system for reporting bugs, or requesting new features. It’s all very arbitrary and through back channels, leading to lots of communication gaps, increased timelines, missed opportunities, and unclear problem statements.

Did we address it?

Absolutely. The feedback from the very beginning is all documented, and everything is transparent. We take that initial feedback, and make real viable solutions based on their needs. The intake board, and one ticket from beginning to end lead to full visibility.

What’s the future?

We’re going to be implementing the feedback right into the design system, living within our component dev and documentation, allowing for both bug flagging (dev), and enhancements to UI/UX requests (design).

Acknowledgements

Through my time at Rogers, I’ve had an amazing team of support. My manager Girish Subramanian has been integral in the success, often acting as our salesman to our other teams. He’s always empowered me to make the change that’s best for us and our users.

Our team of designers within the Working Group and the DC have been working together for over a year now, and are great at being adaptable and flexible. Their feedback and input has been invaluable.