Recently, my colleagues and I were about to embark on a mission to gather requirements for an upcoming release. We had already worked with this particular client and therefore knew that they would have a solid understanding of their existing solution, if not the full capabilities of the Sitecore platform. For the new requirements, we decided to put together some prototypes. I’m so glad we did!

Sitecore’s platform provides a great many ways you can quickly extend it to show alternate paths or configurations, which is perfect for rapid prototyping. Our usual requirements gathering process involves wireframes and whiteboarding to try to get user flows down, but this is much more difficult when working on refining content author experience. Here are a few things you can do to make those requirements gathering sessions go more smoothly:

#1. Security Presets

It can be difficult to talk about securing pillars in the tree, or how a content author might go about securing a page. Showing the default security editing dialogs can be overwhelming. Create a few security presets and show how easy it can be for authors to add security to an item in the tree. This will let you start driving the discussion into what those preset options should be, and who will have access to what.

#2. Component Prototypes

The initial SOW or RFP for your upcoming project probably gave you an idea of the types of content the authors need to be able to integrate onto the page. This is a great time to prototype some components so that users can see what the authoring flow will look like. Some hard-coded HTML on an ASCX combined with a sublayout definition will get the talking started. If you can mock up a custom experience button to show editing properties in Page Editor, this is even better!

#3. Preliminary Spikes

Sometimes you see an RFP requirement and you have to provide an estimate without knowing the full details. Right before requirements discussions is the perfect time to execute some spikes and dig into these questions! Maybe it’s a system integration, maybe it’s a module you haven’t used before, this time it’s all about putting something together to learn and show the capabilities of the system.

This work might be throw-away, but it will mean that during the requirements sessions you will be educated and know how to direct the conversation to gather the details you really need.

#4. Mobile prototype

This one is best for systems where you’ve already built a system and have a responsive design project coming up. It doesn’t need to be perfect, but a few choice responsive media queries that affect the overall layout will give you the basis upon which you can direct the responsive design requirements discussions. As with most things, folks need to see something to really know what they want (or don’t want!).

#5. DMS examples

It’s so easy to set up some basic personalization, this really is an easy investment. I usually recommend having this occur during a later project once the client really understands a component-based build so that the leap to datasource personalization is an easy one.

Prototypes are a Sometimes Thing

You won’t always have the time, or budget, to put together some prototypes before your requirements discussion, but if you can, you should! Also, if you aren’t doing a follow-up project or don’t have a clear understanding of some of the requirements, there may be too many options to prototype so it may not be cost-efficient up-front. In that case, it may be worth having a quick meeting to gather a basic idea, then break to prototype and rinse/repeat!

What elements of Sitecore have you used for prototyping for clients?