When dealing with your Service Catalog, consolidation is more often than not the goal for simplicity. The thinking goes, the fewer items your end users have to choose from the better the user experience. In my opinion bite-sized beats out catalog items that are over engineered, over scripted, and overstuffed with UI policies. Stop building “Swiss Army knife” service requests and build the kind of experience you would get ordering a coffee from the Starbucks app.
Think about it, you open the Starbucks app, and you select the drink you want. A "French vanilla latte", a "pumpkin spice matcha chocolate razzle dazzle", or "mocha something or other" add any additional modifications and bam you are ready to check out. Your Service Catalog should function the same, users don't want to spend their time filling out 15 mandatory fields, this could result in them guessing the right options to select, giving up on their request, or the unthinkable opening an incident!
I've experienced this time and time again “Swiss Army” catalog items, a single form meant for hardware requests, facility requests, and all 100+ applications your company supports and don't forget it also slices and dices! Imagine this same scenario in your Starbucks app. You select drink type, then the type of coffee bean, then the sweetener, the type of milk, then the syrups, and then the style. How frustrating and tedious would this be?
Smaller, modular, and bite sized requests are the way to go. This approach offers multiple benefits such as simpler reporting (less filtering on variable data), reduced change risk, higher maintainability, and modularity. Resulting in teams being able to reuse common flows and variable sets across the platform. So, the next time you build a catalog item remember: “Ease of access = Frequency of Use.”
