2019 was the year that DesignOps became more than just a buzzword. You don't realize how much you need it until you start working at an organization where most co-workers don't fully understand the role and value that a high-performing UX team could be delivering.
When I interviewed for a UX Designer role in Oct 2018, it was evident that the UX team at SAP Fieldglass yearned to grow and mature as a design team. I was intrigued by the opportunity to join a team where I could help scale the team from being perceived as "they make things look pretty" towards "they are a core component of company success."
Just prior to joining the UX team, a decision was made to adopt Sketch as our primary wireframing tool. Axure would still be used in the background for certain projects, but our existing team members would commit to mastering usage of Sketch.
This became a great opportunity to build a reusable pattern library of components that we could share as a team through Invision's Design System Manager.
1) Fieldglass "legacy" components
UI Components that had been evolving in visual design and usage since Fieldglass was founded in 1999.
2) SAP "Fiori" components
A design language developed by SAP in Waldorf, Germany that we and other SAP businesses will be required to adopt to ensure a consistent user experience across all SAP products.
A fellow designer who joined Fieldglass around the same time I did (Kevin) partnered with me to re-create all of our existing "legacy" components in Sketch. We did this all within 1 week. Previously, they lived in Axure, and any time another designer needed to borrow a component, they would open another designer's Axure file and copy and paste the component into their own file.
Kevin and I then brainstormed a process for how everyone on our design team will use the 2 different pattern libraries in our design system. Our goal was to ensure that everyone was always using the latest components, which could only be done by encouraging usage of symbols in Sketch.
{S, K, N, S, M} refers to the first name initials of each of our design team members.
Our team is still getting into the rhythm of figuring out a scalable method for incorporating each update from the Fiori design language. Ideally, all changes from SAP Fiori would automatically appear in our Sketch files, but there is still an intermediary layer -- we need to accept their Sketch library file and have each designer on our team manually install the library on our Sketch files.
However, what has been helpful is the SAP Fiori website of available React components. Our design team often checks with this website to ensure that the components we are using are not only the same ones being used in the Fiori framework by our developers, but also that we're using the latest and same version of the components as the ones in the React library.
How much time should our design team be spending in meetings? What types of meetings do we need to prepare our team for a design-led culture?
"Another f*king meeting"
At the time I joined Fieldglass, there was one recurring meeting a week that involved our UX team. This was called the "UI meeting" that collectively lasted 2.5 hours per week on average. This meeting consisted of our design team, the VP of Technology, and the Director of Engineering.
There were 3 pain-points from these meetings:
1. Design by Committee
Throughout the first ~16 years of Fieldglass, our design team comprised of solely my manager and input from our VP of QA and Director of Engineering. The 3 would make design decisions together and often overrule each other.
2. Solution-ing on the spot
As a relic of design by committee, some design decisions had to "be made quickly" based on personal intuition and anecdotal customer stories -- not very data-driven.
3. Non-equal participation from attendees
The setup of the UI meetings did not optimally afford input from all attendees of the meeting, including our other design team members. Many attendees felt overshadowed as an unintentional impact of solution-ing on the spot.
Drawing on successful design process practices from my previous role at SpotHero, I proposed to our team a weekly meeting called "Show 'n Tell." This was open only to our design team and seeked to address the 3 pain-points surfaced by our UI meetings.
Here is an example format:
Show 'n tells became the most engaging when our entire design team was in-person (i.e. not remote).
Timing the scheduling of these show 'n tells was best when most of our design team needed feedback the most on their projects. This was likely towards the end of the week right after all of our project meetings with various stakeholders.
Our show 'n tell meetings often had design team members not showing any work since they had already elicited feedback from other project stakeholders due to looming deadlines. This revealed that we would never be able to perfectly time the scheduling of these meetings. This led me to start exploring other formats for our show 'n tells, which include breaking them up in to ad-hoc meetings and maybe including Slack polls to vote between different design concepts.
“Michael is a great resource. He has been with SAP Fieldglass for over [12] months and has done so much for the company in building out a better design culture for User Research. I very much appreciate his thoughtfulness on how to approach new designs and bring a fresh perspective to SAP Fieldglass.”
Soon after joining Fieldglass, I realized that championing a design-led culture for our organization required a systemic approach to growing our UX research practice.
Up until this point, our foundation in UX research had been primarily based on a marketing and customer relationship perspective. We had never prioritized enough time for usability sessions and user interviews.
This approach to UX research was insufficient and non-scalable, as evidenced by the fact that we would be building out customer requests that resulted in even more lingering pain-points that were later vocalized by the same customers.
To mitigate the effects of this, our UX team needed to be more proactively involved earlier on in the product development process, when requirements were still raw and pliable.
Some light UX research is likely needed if the following product questions -- which I created -- cannot be answered confidently:
Question from UX for stakeholders
Write answers here
What is the problem and why is it a problem?
How pervasive is the problem? Is this problem mostly addressing a user need or a business (FGL) need? If both, how can we compromise?
Write answers here::
(hopefully this answer will encourage stakeholders to ensure there's a balance between business needs and user needs)
What is the use case(s) or scenarios where the users are experiencing this problem?
The answer to this question encourages all stakeholders to be human-centered.
What research currently exists for this BC or related ones?
(e.g. usage rates and other quantitative data, customer quotes/feedback and other qualitative data)
This question is intended to introduce a data-driven approach.
What percentage of aforementioned users are going to be affected by our designed solution? Basically, how severe is the problem?
This question allows us to pause and think about how our solution can apply to many users, and not just a few customers
How is this problem being addressed (worked around) by SAP, FGL, or the customer today?
This question is here to discourage any solution-ing that other stakeholders have already committed to in their heads
How are we defining and measuring success for this BC?
The answer to this is crucial for stakeholder alignment and what to build and how.
How are we going to prioritize the (multiple) requirements of this BC? i.e. What will be in scope for phase 1?
Hopefully, the answer to this question will entail an element of user empathy and what users would expect in phase 1.
I prepared 2 versions of this template, with one being a publicly disclosable version that could be shared with our sales team and their clients in order to help recruit participants for usability sessions. I labeled this as "co-innovation" opportunities so that our team and our sales friends could utilize these UX research sessions as relationship-building vehicles with our clients.
To round out our systemic renewal of UX Research here at Fieldglass, I introduced a template for managing the logistics of usability sessions. This template also drew inspiration from my previous role at Spothero.
Like other templates I created, I placed this on our OneDrive so that others on my team (and other stakeholders who agreed to take usability notes for me) could easily access the template.
It had been several years since Fieldglass had created personas with the help of a digital agency vendor called FuzzyMath. Since then, our products have begged for more granular and sophisticated classification of our users into new persona types. I started a template to document these emerging personas and encouraged everyone to add any new personas that may have been discovered in other design projects.
Now that I had established these templates for conducting efficient and effective UX research, how was I going to encourage continued usage of these templates and measure their effectiveness?
One way to cement the habit of using these templates was to put them into practice by gathering qualitative data ourselves through collaboration with Professional Services. PS, as we refer to them at Fieldglass, comprises of our account teams, support teams, and parts of our implementation teams. These friends of ours are regularly in direct contact with our clients, and would therefore serve as a proxy to firsthand feedback from our users.
We run these meetings once a month and invite the entire design team. Additionally, we always invite our colleague Chris, who provides quantitative data from our Support team.
Our designers start to piece together qualitative and quantitative data based on questions we ask, such as:
Of all our level 1 cases and tickets submitted to our support desk, how many of them involve [insert pain-point or feature we are concerned with]?
Who is calling in about [this pain-point] and when? From where?
Fostering a design-led culture can only happen when our team collectively and constantly yearns for UX maturity. To ensure that our team was honing their craft and seeing how other companies in the tech world were using UX to solve problems, I regularly sought out meet-ups that were relevant to our UX team's pain-points and coordinated our team attending these.
Additionally, I put together a formal proposal template for our team to attend conferences and other large-scale learning opportunities. This will be re-used for future learning opportunities.
Our product development organization hosts a bi-weekly lunch 'n learn called "Know More" sessions. These hour-long presentations are usually given by developers and rarely by our design team. We took the initiative to sign up for a slot.
In order to decide on a topic for our presentation, we reflected on what pain-points our team was experiencing when collaborating with other stakeholders who may or may not be in attendance at the Know More session. In thinking back to the various design by committee and solution-ing on the spot moments, I decided to create a presentation based around 2 themes that would build on top of each other:
The role of Design at Fieldglass
This presentation included a new proposed outline of how our design team hopes to collaborate with stakeholders (basically by being involved much earlier on in the product process).
Simulating a usability session
We select a volunteer from the crowd to be a usability participant in an actual problem for which we are conducting usability session.
"I bet you the first participant isn't going to be able to find that button. Actually, I'll bet you a boba on it..."
Sure enough, I would've gotten my boba if we had shaken hands on it..
This led me to think of version 2 of our "Simulating a usability session" Know More, which would ultimately resemble a game show format.
Points would be given to audience members who most accurately predicted what each participant was going to do -- whether or not he/she would successfully complete the usability task a certain way, or not complete it altogether.
Of course, the goal of the scoring system for the game show was to demonstrate that no one, not even our design team, could accurately predict how each participant was going to complete each usability task we gave them.
In other words,
"You are not your user"
After debuting the game show at an internal conference, we received a request for an encore session.
And yes, my manager wore his shiny gold game show jacket for each session.
Buliding out a design culture would not be complete without mentioning the strides we took in scaling our hiring and mentoring process to ensure we are building out a solid long-term team.
I was asked by my manager to preapre a written proposal to our Fieldglass director of product development. This became another opportunity to evaluate the needs and gaps of our design team that we wanted to fill with our next 3 hires.
During the past summer (2019), our design team had the opportunity to host 2 interns. I became the formal mentor for one of the interns who was also based in our Chicago office.. I applied what I had learned in my 3 years of experience from my coaching business on the side, which focuses on elevating soft skills for current university students and recent graduates.
Our team ultimately converted our intern to a full-time
Weekly 1 on 1 meetings with my intern
I set up this weekly cadence to help my intern and I reflect on how her internship has been going. "What did you enjoy doing the most? Least? What do you wish to change about how you work?"
Creating a "How I work" template
I learned from my very first UX manager that it's important to outline my working style so that others can understand my preferred collaboration methods, pace of work, and other factors of a harmonious working relationship.
I ended up sharing the template with others on my team, including my manager and my other teammate who was mentoring an intern himself.
