REFLECTION
But first…what does a Salesforce design consultant do?
I worked for Silverline, a Salesforce implementation partner. We were a company of Salesforce experts responsible for ensuring that new and existing clients implemented Salesforce in ways that successfully met their business goals.
As a UX designer, my primary responsibilities were to:
Conduct robust research to understand user needs and complex business processes
Collaborate on holistic solution design that balanced ideal user experience with technical constraints
Design custom Salesforce features to fill in any gaps in the native platform
I've been able to work on lots of problems.
I made the very tough decision to leave my first job at Salsify when I realized that the strongest new designers we were hiring could say something I couldn't yet: "Hey, I've solved a problem like this before." To be fair, every young designer has to start somewhere, but I had been working on the same platform for 5 years and my design experience was firmly rooted in one way of doing things. I was struggling to look at problems from different perspectives and contribute fresh, innovative ideas.
Fortunately, consulting gave me the variety I was looking for. In the following 5 years, I had the opportunity to work on over 20 enterprise solutions, from customer service hubs to patient management databases to loan processing systems. Each project brought a mix of new problems that allowed me the freedom of blue-sky solutioning, and familiar problems that enabled me to leverage and evolve upon lessons learned from other projects. As an added bonus, I became very familiar with the Salesforce platform and how it handles data-heavy screens, complex user workflows, dashboards, and more.
While design problems are truly endless, I'm excited to contribute a lot more, "Hey, I've solved this before"'s and bring a diverse set of design experiences to my next opportunity.
I've conducted lots of research to understand complex spaces.
Designing a comprehensive solution for a client first requires a solid understanding of their business and, let me tell you, consulting opened my eyes to just how many types of businesses there are! For example, even though one of my "specialities" was insurance, take a look at the various products my insurance clients offered:
Private health insurance for individuals and groups
Government-subsidized health insurance
Warranties for large household appliances
Property & casualty insurance for homes, boats and farm buildings
As you'd might imagine, my knowledge of the American health insurance system didn't quite come in handy when it came to understanding the complexities of farm insurance. But I got very comfortable diving headfirst into the unknown, and systematically finding clarity through designing and executing on research programs that combined interviews, curious listening, work shadowing, process mapping, documentation analysis and secondhand research. As an added bonus, I also lean heavily on the interview techniques I learned as a journalism undergrad - I'm constantly amazed by how much my journalism education helps me in product design every day!
I've facilitated design workshops for diverse audiences.
I'm a big believer in co-creating solutions with users and my fellow teammates through design workshops. It creates shared ownership that makes users excited to engage with the final product, and introduces an element of play that is so important for our creativity.
To do this, I've facilitated both in-person and virtual brainstorming, card-sorting, sketching, dot-voting, design critiques and more. While it's important to know how to prepare the best exercise for a given problem, I've also learned that a big part of running a great workshop is being able to read the room and roll with the punches. I've facilitated workshops with 20+ participants where everyone remain engaged throughout, and workshops with 3 people where I had to pivot my approach on the spot to keep them focused - every audience is different! To be prepared for any situation, I love keeping my facilitation skills fresh by finding low-risk opportunities to run exercises with teammates and providing coaching.
I'm passionate about holistic solution design.
Since the Salesforce solutions we implemented always had a mix of native and custom features, it was very easy for us to deliver a disjointed user experience without a holistic understanding of the desired end-to-end solution.
As a result, I love journey maps, storyboards and wireflows: artifacts that illustrate the end-to-end experience in progressively more detail and maintain team alignment as we dive into pixels and code. I constantly encourage my teams to not think about features in isolation, but rather in context of where they sit in the entire workflow: What happens right before this? What happens after this? Can users seamlessly move from one feature to the next?
When in doubt, I press my teams to test their ability to tell "the simple story" first. How would we tell a kindergartener how to activate the warranty on their brand-new dishwasher? If we find gaps in our knowledge at that level, we'll definitely run into problems later as we're waste-deep in complex business logic and data.
I know the importance of being a "platform expert."
Even though I focused on custom development on Salesforce, I still needed to be sure that we weren't jumping to a custom solution when an existing one would do. This is true when designing on any platform; treating all design challenges as blue-sky is the surest way to create a disjointed and subpar user experience. I believe that designers need to understand the context in which they're contributing their design, which requires being aware of the rest of the product that you're designing within.
While it's unrealistic for anyone to have a comprehensive understanding of Salesforce's massive product offering, I was encouraged to make the most of my resources to stay up-to-date with the parts of the platform we used most. I went through product training, watched solution demos, sat in on sales calls, kept up with release notes and built relationships with the Salesforce experts at our company so I could shoot over a simple, "Have you seen a solution like this before?" before diving into a custom design. I also love staying close to what my fellow designers are working on, and borrowing concepts to expand our shared design library.
I can collaboratively make decisions using data.
While resource costs and timelines impact decisions within every product organization, they are conspicuously front-and-center in consulting. Any decision that was in conflict with contracts, timesheets or invoices needed to be made and defended with intention.
In this environment, I became very comfortable with impact vs. effort conversations to define the best solution within our constraints. I leveraged the qualitative and quantitative insights from our user research to articulate the "impact" as we weighed solution ideas, balancing the frequency with which we heard a particular insight with the relevance of the person providing the insight and the influence on core KPI's. These conversations were wonderful practice for removing my ego from decisions (a difficult but valuable exercise for many of us designers!) and thoughtfully collaborating with developers.
I'm obsessive about close engineering and product relationships.
While great communication and collaboration between design, engineering and product is crucial for any team, staying in lockstep with my cross-functional counterparts was especially critical in consulting. Clients want consistent updates on your progress, which means that you're often sharing in-flight work before you feel comfortable doing so. And while you can present this work with all the disclaimers that you want, every presentation of work sets client expectations.
Early in my consulting career, I shared a few designs with a client straight from my raw Sketch files. While the client loved them, I put my team in a rough spot; none of these designs had been vetted by developers and represented far more work than we'd initially planned for. Since then, I've been adamant about staying close to my teams with recurring syncs, design reviews and co-creation. Though I never regret identifying a solution that users love, I've learned that doing so in collaboration with my engineering and product counterparts leads us to making better development and roadmapping decisions that we're all invested in.
I love a thorough design system.
I spent my first year as a product designer building mockups in Adobe Illustrator. I had never heard of design systems and very loosely maintained a consistent UI by copy and pasting design components from one file to the next. (Those were the dark days!)
As we started formalizing our design practice and building out our first design system in Sketch, I was blown away by how much faster I was able to design. Imagine my shock, then, when I started designing on Salesforce and was introduced to the Salesforce Lightning Design System (SLDS). The component library is extremely thorough, the documentation is comprehensive yet easy to follow, and the corresponding Figma library is a joy to use. Not only did it help me design much faster, but it also changed how I design. I turn all of the custom UI I design into reusable Figma components and document usage guidelines for my developers to help us design faster and smarter.
I'm used to working in fast-paced, ever evolving environments.
Consulting took ad-hoc meetings and shifting priorities to the next level. It was very rare that my calendar looked the same in the afternoon than it did in the morning. I've given a presentation to a client executive two weeks early and with five minutes of notice because he had a last-minute cancellation on his calendar. I've completely revamped a design workshop agenda on the spot because we had the wrong attendee list, and have lost track of the number of late nights I've worked to put out unforeseen "fires" that are a natural part of consulting. I even once had a client in the UK who would book 2-4 hours of additional meetings for the next day (all of which I had to run!) while I slept.
While I'd love to not relive some of those stressful moments again, I'm very familiar with adapting to changing needs. I've learned how to over-communicate with my managers and teams about my workload, be transparent about my bandwidth and the resulting trade-offs, and amass a set of tried-and-true templates and approaches that help take some of the pressure off when last-minute design needs come up.
While I'm excited to move back into an in-house product company, I'm extremely grateful for the time that I spent as a Salesforce consultant. It gave me exposure to one of the most popular and expansive enterprise SaaS solutions around, and I'll take the lessons I learned about designing data-rich interfaces and workflows with me for the rest of my career. It also expanded my appreciation for the design toolkit and its ability to bring intention and care to unpredictable situations. Most of all, I loved being able to interact with so many groups of users, and to provide engaging, thoughtful experiences that helped us deliver solutions that they loved.
