When I arrived at Crownpeak, the product development process was engineering driven. The engineering team chose what to work on and asked a designer to deliver assets by the end of the sprint. That is a broken process, and it was my first and highest priority to fix.
As I started to build an approach for the UX team to follow, I focused on four key areas.
Crownpeak was struggling with a poor quality product experience, leading to customer attrition and low advocacy. A new approach to product strategy and delivery was critical in ensuring all new work delivered was both useful and useable.
At its core, this was a paradigm shift for the product, engineering, and UX teams away from being measured on quantity of product delivered to quality.
A core challenge for the designers was the project intake process. Feature requests would come in without any context. You can’t design great experiences without understanding the problem.
Consulting with the designers, I built a project intake template. I asked the team to work with their partner product managers to fill out the template for each project BEFORE design started. I worked closely with the designers and PMs initially to move beyond simple/generic responses and dig into The Why of each particular effort.
The template included questions like:
Initially, it was a lot of documentation that over time scaled down. But it set a precedent that Engineering and Product would need to be able to answer these types of questions before design started and led to fruitful conversations between the three groups around what types of solutions would be the most impactful.
Following alignment from Prod/Eng/UX, the designers would lead a cross-functional Kickoff to help the business understand what we would work on and why. This was frequently a great sense check to see if CS, Support, and Sales agreed with our assumptions and understanding.
Outcome:
Designers felt like they were losing discussions about the design direction because the conversations were frequently “I like this” vs. “I like that”.
I set an expectation that designers come to discussions with data to support or oppose solutions under discussion. The designers led the reframing of these discussions, which further increased alignment and helped speed decision making. As the culture shifted, developers and product managers began bringing data to the discussions as well.
As the designers worked through projects, I focused on building the infrastructure to access data. I built:
Outcome:
UX and design as a function was a black box. The process for creating and delivering assets was inconsistent across designers and the quality varied by project. I drove four initiatives to open up the process to our cross-functional partners.
KickOff - Every project had a cross-functional kickoff including both product development and business team members. I built a Keynote template for the team to use that included content from the intake template (mentioned above) and a project timeline with phases and activities. The outcome of the meeting was everyone knew what problem we were solving, when their engagement was expected, and when the UX team would deliver. The timeline was shared at every check in.
Design Checklist - As a team we created a checklist of items that needed to be considered before handing over to engineering. Those items included:
Developer Handoff - Instead of local files and Invision prototype links, all Sketch files were stored in Abstract via the Sketch integration and the link was pinned in the project Slack channel. Everyone knew where to find the most recent version of the file and had the ability to inspect every element. This became much easier when the team transitioned into Figma.
Design QA - I added a step in the SDLC and Jira for a Design QA. This is an requirement for the lead designer on the project to ensure the coded experience matches the designs, pixel for pixel. This type of review had been happening infrequently and developers had little incentive to check with the designer on changes. Enforcing Design QA as a requirement at the end greatly improved communication earlier in the development process to reduce developer rework. Developers reached out to ask questions and make suggestions where there had been little communication previously.
Outcome:
Efficiency was primarily driven through the creation of a shared design component library.With all files moved into Abstract, library files became accessible across the team. I set an expectation that:
While designers owned larger projects, I worked with PM and developers on smaller efforts or bugs. Using the library, I was able to point to components to use without needing to create design artifacts.
Outcome:
