Currently, I’m employed at Salesforce as Senior Product Designer working on Salesforce Data Cloud. There are many parts of my work I would love to showcase, however in order to reserve visibility for only publics designs of our products and hinder duplication I can only speak to people in person about a good portion of my work. In the meantime, I can tell you about my processes and give a glimpse at what I do.
The following work is password protected. Please reach out to me at email@example.com to get access to these projects.
Understanding business needs in tandem with user needs is essential for a project ask at Salesforce. Every project starts with understanding from the beginning of a release cycle. What is the vision? What do we see this release accomplishing? What are the user goals? What are the business goals? Once there is a shared understanding from a high level do we dig deeper into the project asks.
Building relationships is integral with my work at Salesforce. I directly interact with Product Owners and Developers to understand the user needs, business needs and developer needs. We seek to understand what are the key jobs to be done the user needs to take care, and how might we help our users accomplish those jobs.
Depnding on the scale of the necessary solution, I collaborate both cross-discipline and cross-product to make sure the work we do aligns closely with similar work in other product area and is consistent with the Salesforce System.
Designing a Product is my bread and butter at Salesforce. The type of deliverables I provide for a project vary depending on the ask. For released based UI work, usually end goal would be for me to provide a high fidelity design prototype with design specifications. However, my deliverables can also be the following: detailed workflows, design documentation, storyboards, Information Architecture Specs, product recommendations.
My process post requirements gathering usually involves sketch iterations > Concepting > Wireframing > Visual Design > prototyping > user testing, rinse and repeat. Not every part of the process is used during each project (and not always in that order) but they follow the same general direction.
Every day I must be more than just a design of our products; I must be a Design Partner. With the product teams I am embedded in I collaborate closely with them by attending scrum meetings, release planning sessions, product offsites, sprint reviews, etc. I also educate and evangelize the work I do and the process I use through hosting regular design meetings, hosting design workshops, and being understandably flexible for delivering design solutions. If something is not feasible, then I will work directly with the team to find a solution that satisfy the customer need, the technology need, and the business need.
Design cannot exist without research. I conduct research on the design asks I create to acquire directive information regarding the current design status, and other guiding goals. I have conducted and/or helped facilitate various design feedback sessions, cognitive walkthroughs, guerilla user testing, and customer focus groups.
I analyze my data and sometimes my cohorts data in many different fashions, using different approaches such as thematic analysis in identifying important themes, or Affinity Diagramming to find overrarching patterns. These are just examples of some of the tools I've employed to analyze the data.
An important thing to point out here is that during research I conduct I try to have someone from product or engineering attend the calls or help me to analyze the data. They themselves will either benefit from seeing their product in action, have questions that could lead to important insight, or find things I might otherwise have not found as a pattern.
I practice in Lean and Enterprise UX. Rapid iteration, collaboration amongst design, research, product, and development. Gather feedback, and iterate on designs. Test designs accordingly. Rinse and repeat, then delivery. Balancing all this at both a release scale and within a 2 week cycle depending is my day in and out.
It is my job to know both effectively, as different teams call for different work pace and delivery cadence. I've worked directly on product teams that work deeply in an Lean method; delivering rapidly and iterating quickly. I've also worked on many continouous live projects that have required many release phases and iterations. It's important for me to know both and adjust my process accordingly, all the while being able to deliver a good solution for the customer.