Many times when we begin a project we start by sitting down with the user and drafting a requirements document. After a few days of organization we come up with wireframes and a general idea of what we understand, and then we wait for user feedback. This is the way things are done, but is it the best way? In SharePoint creating a page and adding a web part is pretty simple and the configurations take a large amount of the time. What would happen if we designed these sites with the user, instead of spending as much time on back and forth communication.
Sarah works for the Finance department of Your Company, and she is not a very technical user. You send requirements documents back and forth and frequently get called with questions. What if instead you went to work for a day with Sarah and studied how she used different systems? You create a page with her by discussing her issues and actually showing her the web parts and list settings. You would catch the smaller issues that tend to arise later in the process being improved upon. In addition, you create a relationship with your client of working with them, and not just getting a task done. This method also allows the client to see their requests in action, and feel a sense of confidence when approaching unfamiliar territory.
Sarah decides to automate the sign off process for the use of the petty cash fund, and asks for a workflow to be triggered automatically, and then for the document to be locked. Without background knowledge of SharePoint, the user might not take into consideration that if the user needs to change the document type or add additional considerations, they may not have access to do so once the approval starts. By sitting with Sarah you save time discussing the pros and cons of automating the workflow, and the user is now able to reference visible information to further explain their ideas. In addition, Sarah now gets to see the maintenance tasks that may be required, and ask questions about other features the user may not have considered due to lack of exposure to SharePoint.
Another issue that we commonly see when designing systems is the difference between reporting, and inputting information. Many times the user who is in charge of sponsoring the project is not the primary user of the system.
Sarah is an Administrative Assistant and uploads much of the information into the Finance site, and her manager Jerry is the lead for the project. Jerry wants to see the username, description, purchase type and location of every user, and adds this to the requirements document as required fields. Sarah however knows that users frequently put the wrong purchase type and would prefer if this information was input by the finance team. Without discussing with Sarah, Jerry now has a new system, and a new issue that he was unaware of because of his high-level position.
Is this an issue within the team, or is it the job of the consultant to think of the maintenance issues that may arise in the future? If you sit with Sarah, issues such as this may be realized much earlier in the overall project timeline. Often times, we may not have the opportunity to work with the actual audience being served, which prevents us from predicting maintenance issues that may occur later, or we end up with designs that are not intuitive enough for new users.
Designing with your user is a great approach for projects with close deadlines, changing requirements, and non-technical users as well as users unaware of the many uses of SharePoint. By putting a little time aside to work with the user, instead of trying to deliver a finished project at an appointed deadline you can greatly enhance the customer experience, and also save you and your development team from many issues that may be lost in multiple translations.
Special Thanks to Mark Drespling for his input during the editing of this article!
