A multi-million dollar enterprise case management tool has consumed the past few months of my work life. Along with a team of front and backend developers, business analysts, scrum masters, and project leads two unique solutions have emerged: a Salesforce Community for customers and a Salesforce Service Console for those working the cases. As the projects progressed, I found myself saying, “Well, next time we’ll know to…” or “I wish I would have…” And so I began to document my lessons learned as we progressed through sprints.
In tandem with the first case management project, I’ve started working on a second case management project for a different client to improve efficiency of service and support for HR. Already, we’re tackling the project initiation in a very different way – a user story map was created during discovery instead of a month of demos of the current system from the first project client. Below is a checklist of items I’ve learned to look at, particularly for service design in Salesforce. It is ever growing and would benefit from any additions you have.
- What are the needs? Try to keep the client, SMEs, stakeholders, etc. from the phrase “I’m envisioning a dropdown with different choices for _.” Instead of writing that vision down as a requirement try summarizing the need you hear from what they say (e.g. “so it sounds like you need to be able to _. Why is that?”)
- Gather styles for header, footer, links, list views, navigation
- What will be your default sort on list views?
- Review style standards early on
- Review interaction standards early on
- Does this need to be responsive? (#duh)
- Decide case type (camel versus sentence). Sentence case in Salesforce can be very challenging.
- Dropdown default value (none, please select)
- Field label rules (e.g. Colon at the end? Question mark after field labels posed as a question?)
- What related lists/tables should exist on page details? Is consistency important?
- Interaction of tabs and subtabs (pretty specific to Salesforce Service Console – one of my least favorite native functionalities in terms of usability)
- Trust your gut. If something isn’t usable, if the project is mismanaging UX efforts let your PL know and move forward as you see fit. It’s terrible creating a solution you could’ve improved upon simply by speaking up
- How will statuses and routing automation be handled?
- Review constantly and don’t be afraid to create bugs and improvements – cover your butt for when the PO or client says something is wrong (then you can just tell them it’s logged and they need to prioritize)
- Empowers PO to prioritize with some added ease because they don’t have to find these updates AND prioritize
- Have a source of truth for Acceptance Criteria for a particular process. Identify a way to tie bugs and improvements. (Had a BA way of documenting – spreadsheet, UX way of doing – stories, etc). Consider using “related to” feature in Jira
- Stakeholders do not know processes or needs as intimately as active users
- Schedule usability testing early and often. It’s the best way to make design decisions and stop long guesstimating “I think users would prefer this” conversations
- What metrics are users measured on (SLA will likely be involved. Consider how incentives and metrics affect your design)
- Information Architecture/Categorization is not a group activity
- Need a way to manage categories