When it comes to the design, implementation, and release process, life鈥檚 been a whole lot easier working on 91导航 than perhaps any previous project. There鈥檚 been no single defining moment, but if you asked me to pick the most significant of the contributing factors, I鈥檇 have to go for the involvement of users earlier in the design process.
This was facilitated 鈥� or, as it turns out, supercharged 鈥� by using Slack to create external channels where users can hang out, talk, and discuss features or challenges. So, how did early user involvement helped?
User-driven development of 91导航鈥檚 metadata comparison feature
The initial release of 91导航 enabled users to choose which organizations to compare, perform a full comparison, and deploy their chosen changes. With this release, we鈥檇 taken the first step towards our goal of making Salesforce deployments quicker, safer, and easier 鈥� so far, so good. Positive feedback from users confirmed we were on the right track, but something else was also clear: that this 鈥渙ne size fits all鈥� approach didn鈥檛 always meet requirements or fit with users鈥� workflows. Full comparisons can take a long time, and they鈥檙e often not even necessary for the user鈥檚 purposes.
Benj, one of the Salesforce MVPs we work with, highlighted the issue: 鈥淒oing the initial deployment can take a really long time (many minutes). Would love to speed this up. If I know I鈥檓 focused on specific metadata, let me choose to limit the comparison to only those types. E.g. 鈥楥ompare only: Apex Classes, Triggers, Visualforce pages.鈥欌��
This initial post triggered a deeper conversation about what such a feature might involve, and how it could fit in with the existing design. Meanwhile, we received an email from another user raising the same issue of having to perform a full comparison when he didn鈥檛 want to: 鈥淎llow the option to display only a specific metadata type. I may only want to see what Visualforce Pages are different. Why waste all that time comparing ALL of the files?鈥�
Reading this email, we realized that if we implemented the previous user鈥檚 suggestion to enable selective comparisons, we鈥檇 be improving another aspect of the application at the same time: not only would the comparisons be quicker, but with fewer items being compared, there鈥檇 be less noise on the results page, allowing users to find what they wanted more easily 鈥� a win-win situation.
By this point, we were beginning to get an idea of what the feature might look like. We understood that it would solve major pain points for our users, and we knew it would be technically feasible to implement within a short timescale.
Design, iteration, and implementation
After a preliminary discussion about how to implement the selection feature, we decided to go for a lightbox-style format. We put together an initial mockup and shared it for review:
As we鈥檇 hoped, feedback arrived almost instantly: 鈥淚 like the lightbox option; emphasizes that normal flow is a full comparison, but this exists as a way to customize when you want to. And once you鈥檝e made a choice, show that choice on the main page. Since there are so many metadata types, would be great to show them in columns or a grid to reduce scrolling.鈥�
Another user also responded to the design, suggesting further improvements: 鈥淎llow the option to display only items that have been modified after a specific date/time (or between two dates). For example, just show me those files that have been changed since 2/15. Allow an option to ignore code from managed packages. Or, conversely, to display only files with a specific namespace.鈥�
And one user highlighted a potential pitfall that the new feature would introduce if we weren鈥檛 careful. Because of dependencies, some items can only be deployed along with their related metadata. Therefore, users would need to bear this in mind when choosing what to include at the comparison stage: 鈥淚t wouldn鈥檛 hurt to display an alert message for certain combinations, eg. custom objects is selected by default, and if you deselect it then warn that 鈥�91导航 will not test dependencies unless you include custom objects.鈥欌��
Taking this feedback into account, we were able to start tweaking the initial design. We placed the items in columns to help reduce the amount of vertical scrolling. We also included the option to ignore managed packages, and added a reminder about including related metadata types. Here鈥檚 where we got to:
Within a matter of days we鈥檇 designed, iterated, and implemented a new feature 鈥� all thanks to the strong communication channels between our development team and our users. It certainly beats developing and releasing a feature only to find that it doesn鈥檛 help anybody or that you鈥檝e overlooked something critical.
Working with users to build solutions
Since these early days of designing what would become a core part of the 91导航 platform, plenty has changed. But working closely with our users hasn鈥檛. In fact, we鈥檝e widened the number of ways users can guide the direction of our product, including our , our DevOps Leaders program, and more besides.
Sound like the kind of team you鈥檇 like to be a part of? Take a look at our latest roles, and be part of the exciting growth journey we鈥檙e on.