Microsoft MVP Wes Preston shared with us best practices for building an Intake/Request list, a simple but often overlooked task. Wes started talking about how these lists are efficient, easy to track, and logged, which makes utilizing them far more effective than tracking down your IT Manager in the hallway. He then took us through the pre-build, build, and post-build stages for these lists.
Before you build a form, you need to think about how and why it’s going to be used. Think about the frequency with which it will appear, and how it could possibly change over time. What do users want from this request? What roles are involved? These questions will help you frame the content that is going to be needed for the form. Think about the metrics you will get from the form: Will they give you the information you need? In addition, Wes recommends that you think about user adoption BEFORE making your form. If it is likely that no one will use the form, then there’s no point in making it in the first place. Think about the information architecture. Where is this form going to live? Is it going to be on a sub-site somewhere or a stand-alone form? Who is going to be the owner of the form? All these considerations will help you make a more usable form.
When it comes to building your form, you will need standard criteria like name, description, type, created date, etc. Obviously, this data will change based on the purpose of the form but, as general information, it’s a good place to start for most tasks. When you are building your form, you may notice that you have fields that only need addressing after the first part of the task has been completed. This issue can be easily dealt
with by setting up a simple workflow. By setting certain fields to only show up after the task has been initiated, you can keep things clean and simple for the end user. After all, there’s no sense in asking questions that do not yet have answers. Another thing to consider when improving your forms is to set the views to be different depending on the role of the person viewing it. This makes sense as a developer may need different information than an end-user does. As Wes noted, you can set up this form and workflow through SharePoint Designer, though be warned, in SharePoint 2013, Designer ONLY offers a code view.
Once you are happy with your form, go back to the questions you asked yourself before the build and see how you did. Make sure that before you release it to the masses you test the form with other people in your organization to see how it works through a couple of cycles. This will help ensure that your form is free of hiccups and ready for broad use.
~Team Bamboo
