The Flexibility and Efficiency of Use principle states, “Shortcuts — hidden from novice users — may speed up the interaction for the expert user so that the design can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.”… Read the rest
The principle of Recognition Rather than Recall states, “Minimize the user’s memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another. Information required to use the design should be visible or easily retrievable when needed”.… Read the rest
For the Error Prevention heuristic, it states, “Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action.”… Read the rest
The principle of “Consistency and Standards” states, “Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.”
If you know me, you know I’m a HUGE fan of consistency. If the same thing has different names, formatting, or syntax, my eyes cannot unsee it.… Read the rest
The principle of User Control and Freedom states, “Users often perform actions by mistake. They need a clearly marked “emergency exit” to leave the unwanted action without having to go through an extended process.”
Fortunately, Salesforce already has some built-in mechanisms to support this.… Read the rest
The principle of Match Between the System and the Real World states, “The design should speak the users’ language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.”… Read the rest
The Visibility of System Status heuristics states, “The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.”
Here are some examples of how to apply this principle to Salesforce:
In 1994, Jakob Nielsen of the Nielsen Norman Group wrote 10 general principles for interaction design. These principles are called “heuristics” because they are broad rules. They are not specific usability guidelines.
They apply today as much as they need back then, whether it’s to static .html… Read the rest
People have been using websites and web applications for decades. As such, they preconceived notions on how things should work.
For example, they identify buttons and links based on appearance, like rectangles and underlines, and know how they should behave before they interact with them.… Read the rest
As a Salesforce consultant, can you be paid for time not spent in front of your computer?
To answer this question, let’s take a step back in time for a moment, and let’s examine my personal journey.
My professional career started as a software developer.… Read the rest
Last month, I wrote an amusing email about not making assumptions. The topic was personal, so here is a short story about one that’s professional.
My tax receipt application for Canadian nonprofits requires the managed package called Salesforce Nonprofit Success Pack (NPSP).… Read the rest
While working with a new subcontractor, it quickly became obvious we have different approaches to project implementations.
They have very strict labels and rules. If they consider themselves as a subcontracted employee, they behave in this manner. If they are considered partners, they behave in another way.… Read the rest
Today I’m excited to announce an expanded mentorship program!
My 1 hour coaching call is now called a 1 hour mentoring call. The service stays the same, but the price will increase from $250 USD to $500 USD on April 1st.… Read the rest
I’m currently working on a project to migrate a client from Raiser’s Edge to Salesforce. Since I don’t know much about Raiser’s Edge, I asked a boutique agency to assist.
The agency gave me a fixed price for the project, which was my preference.… Read the rest
One of my students is a Salesforce consultant. He’s recently made the transition from full-time to independent and engaged my services to help him close a relatively large project.
He started by asking me how he should present himself. Should he start with all his credentials, his years of experience, the work he’s done on similar projects?… Read the rest
When you’re a more experienced Salesforce consultant, one of your usual tasks is to help write user stories. Typically, the consultant writes the functional part of the story, while the business analyst fills in the rest.
The question then becomes, how much detail should you add to the user story?… Read the rest
This question was recently discussed in an online forum recently. To answer it, let’s look a little closer at what it means to be a Salesforce professional.
As the recent series on Salesforce roles explored, titles are given to people doing a certain type of work.… Read the rest
The last two roles are pretty straight forward, so we’ll combine them into a single email.
These days, the Administrator (Admin) is more than someone that configures users, resets their password, and adds some fields. In some cases, they are a one person army.… Read the rest
Most of the roles described so far lean towards the technical side. Most of them require good communication skills, but as a Business Analyst (BA), those skills are core.
BAs are like the glue of the project. They keep everything connected, and know a little bit of everything.… Read the rest
The single person responsible for the development of Salesforce projects is the Development Lead (DL).
In this context, development doesn’t just mean apex classes and triggers. It includes Visualforce pages, Lightning Web Components, flows, managed packages, connected apps, and even configuration.… Read the rest
There are too many Salesforce clouds to be a master of all of them. When someone specializes in a single cloud or platform, and knows it in incredible detail, they are called a Subject Matter Expert (SME).
SMEs are important to have in a project when a very granular level of detail is needed.… Read the rest
As an independent Salesforce consultant, also known as a soloist, you need to have certain document templates.
When I start an engagement with a client, it typically starts with a sales call. If everything is aligned, I submit a 4 or 5 page proposal.… Read the rest
On smaller Salesforce projects, the Lead Consultant (LC) is usually the same person as the Solution Architect (SA). On larger projects though, it makes sense to divide this role into two.
When both roles are involved, the SA focuses on researching solutions, doing proof of concepts, and supporting the LC, and the LC is the single person responsible for the overall solution.… Read the rest
Whenever data is involved in a Salesforce project, you’ll typically find a Data Architect (DA).
DAs are masters of data. They analyze it, process it, protect it, and make recommendations based on data requirements.
Additional responsibilities include
If you’re technical and talking to clients just isn’t your thing, consider the Technical Architect (TA) position.
TAs are responsible for the technical elements of the Salesforce platform. This requires strong technical knowledge, understanding concepts such as event-driven and data-driven architecture, and platform events.… Read the rest
If the Program Architect represents the football coach, then the Solution Architect (SA) represents the quarterback.
The SA is often found in the field, beside the other players, and calling the shots. They decide and are responsible for the solution, from a functional perspective.… Read the rest
I had a great conversation with a student of mine today. We spoke about how junior Salesforce consultants believe senior consultants know everything.
They perceive senior consultants as a large book of knowledge, who can immediately find the right page with a moment’s notice.… Read the rest
One step down, from the Enterprise Architect, in terms of visibility, is the Program Architect (PA).
The main responsibility of the PA is the strategy of the entire program within Salesforce. A program is usually composed of one or more projects.… Read the rest
In the Salesforce ecosystem, the Enterprise Architect (EA) has the widest technical view. They see the complete end-to-end architecture, and are not limited to just the CRM.
This means they understand and are responsible for
They are very technical, are able to discuss approaches with fellow architects, and ensure fellow architects are aligned.… Read the rest
In the realm of Salesforce, there are plenty of hats you can wear.
The responsibilities for some of these hats (or roles) are straightforward. Other roles have multiple names and meanings, and other-others overlap multiple roles (also considered to be a *really* big hat!).… Read the rest