Managing client expectations throughout a project, communication progress and facilitating consistent momentum is paramount to implementing SharePoint 2010. IncWorx's core methodology is one that is holistic and integrated. We are firm believers of establishing a team of SharePoint Experts, User Experience Designers and Business Analysts to adequately refine SharePoint to drive results within your organization. Without diminishing the perceived complexity of this - the process is quite simple, and a team is constructed specifically for the project scope. IncWorx Consulting has learned over the years that one of the most important factors, as simple as it may sound, is project documentation.
"Many people don’t see the importance of gathering the necessary explanatory documents that define what you did all throughout your project development. Either that, or they treat the documentation process as a simple putting-together of all the sketches and wire-frames generated. We should, nonetheless, give more relevance to this final, whole-project document."
For the record, it doesn’t mean a 500 page document or something of the sort. It means something more on the lines of a compilation of the strictly necessary documentation generated by your design process, in an orderly fashion.
Why does it matter so much?
There are a number of reasons that project documentation is critical to a successful SharePoint 2010 User Experience and Implementation. Below are a number of reasons that are mentioned to answer this particular question:
Future project reference
Be it as good or bad example (what we did right or what we should not repeat), you have a permanent record of what happened during the detailed development of your past projects to go back to. This helps IncWorx Consulting share best practices with clients and guide them in the right direction when making decisions throughout the project. In addition it’ll help constantly improve working process and, gradually, results that both the IncWorx team and client benefit from.
Organizing ideas throughout the development
It’s easier to maintain order with the necessary documents at your disposition to answer questions throughout the process about previous stages, what has been done and how much has been done of it. Keeping a well organized document and sharing progress with the client is a key process to Agile methodology, and keeping momentum strong.
Introducing new members to your team
It’s easier to help a new member of your team in the understanding of your working process when you have previous documents, because then they have something to look at and you won’t have to keep reminding him of essential points afterwords. Of course, this won’t eliminate your need for a formal introduction, but later on it will make the need for further questions a lot lesser.
Improving Working Process
Looking back at what was previously done, do you think you’re missing a step? Are you being too unclear and messy at some point? Are there miscommunications among your team members from one stage of the process to the other? A document can help you answer all of these.
What, then, should this document include?
It actually depends on the type of project you’re working on and the steps that project includes. IncWorx, as I'm sure you've realized, specializes in SharePoint User Experience Design and Implementation. Considering, thought, the hypothetical scenario that you’ll be working on an implementation from scratch, the document should ideally include the following:
Project introduction
Basically, just answering the following questions gets you all the way across:
• Who’s the main client?
• Which is the main objective?
• What is the driving factor of business value?
• What’s the client’s vision of the project?
Written briefly and to-the-point, to have as the background of the whole project.
A user centric experience requires identification of users and user research
This means getting down to creating personas. And of course, the document will consist of all the created profiles after identifying the users and their needs. Having clear and complete persona profiles will support later stages in the design process.
Website content requirements
After deciding on the personas, what should the website have to offer them? Keeping in mind that we have now both, the users’ and the client’s needs documented, we can list requirements as a checklist to be later on verified and revised. There are many ways we can do this in an organized way to suit our needs at the moment.
Concepts to apply
How will these requirements be met? This stage basically answers the question ‘What will we do to meet the previously established requirements?’, considering the issue in terms of user reactions and the concepts to apply in order to generate these reactions.
Information Architecture
A formal or informal diagram of the information architecture map is a must, as it’ll be an important guide throughout the later stages of the design process.
Interactions
This stage in the documentation process includes basic diagrams of the main interactions that will be applied in your website. Such interactions might include basic error notification, success notification, link behavior, drag and drop interaction behavior, among others. Make sure to have your feedback clear on each interaction diagram.
Navigation
Navigation design for a SharePoint Implementation is based on two methods; one consists of working with application diagrams to map your whole navigation system - or, based on client comfort level - with site maps.
Concept designs and prototypes
It is important not just to include the final, clean wire-frame, but also some of the sketchy beginning ones, the ones in lower qualities with representative elements and some of the rejected ideas to illustrate your process.
Usability testing on prototypes
Trying to keep it as lean as possible, usability documentation can include the final results and statistics. You may include the scripts you created as guides for you and your team if you tested it through focus groups or personal interviews, too. But you may have tested using a device such as eye-tracking or mouse-tracking, in which case you could just include the resulting generated maps.
Development plan and technical specifications
With the previous documentation and research, development decisions can be made. These decisions involve the technologies that will be used to create the application that has been designed, justified by the requirements that need to be met.
Style guidelines and patterns
The final specifications about colors, indentations, images, among others. These have to be well established and justified, too, in order to serve as a guide throughout the development process to maintain the visual design standards.
In Summary
As it may seem a "project bible" is in the making, it doesn't need to get out of control. The project and client dictate the right amount of documentation. All in all, at IncWorx Consulting we firmly believe is a holistic approach to Implementing SharePoint 2010 within your organization - and documentation is one that we recommend staffing and including in your next project! It helps keep some order in the messy chaos that creative work generates.
IncWorx wants to be your SharePoint Partner. Our Creative Resources are available and ready to talk to you about creating a unique SharePoint User Experience.
Give us an opportunity to show you how we can help your organization get the most out of your SharePoint Deployment.
More About the Author
David Jelinek
National Creative & Marketing Director
Email: djelinek@incworx.com
Phone: 630.404.9413
More About IncWorx - Visit our Website
IncWorx Consulting is the premier consulting company for SharePoint, we service clients in: Chicago, Indianapolis, Minneapolis, Cleveland, New York, Houston, Topeka, Milwaukee, San Antonio, San Diego, Dallas, Houston, Austin, Tampa, Orlando, Boston, NYC, San Diego and Los Angeles.
We specialize in SharePoint and have invested significant time and resources into our SharePoint practice. We take a holistic approach from inception to delivery which provides the best possible outcome for our clients.
Rodriguez, Pamela. "UX Project Documentation: Answering Why, What and How." Weblog post. UX Booth. UX Booth, 14 Dec. 2010. Web. 3 Jan. 2011. <http://www.uxbooth.com/blog/ux-project-documentation-answering-why-what-and-how/>.
"Many people don’t see the importance of gathering the necessary explanatory documents that define what you did all throughout your project development. Either that, or they treat the documentation process as a simple putting-together of all the sketches and wire-frames generated. We should, nonetheless, give more relevance to this final, whole-project document."
For the record, it doesn’t mean a 500 page document or something of the sort. It means something more on the lines of a compilation of the strictly necessary documentation generated by your design process, in an orderly fashion.
Why does it matter so much?
There are a number of reasons that project documentation is critical to a successful SharePoint 2010 User Experience and Implementation. Below are a number of reasons that are mentioned to answer this particular question:
Future project reference
Be it as good or bad example (what we did right or what we should not repeat), you have a permanent record of what happened during the detailed development of your past projects to go back to. This helps IncWorx Consulting share best practices with clients and guide them in the right direction when making decisions throughout the project. In addition it’ll help constantly improve working process and, gradually, results that both the IncWorx team and client benefit from.
Organizing ideas throughout the development
It’s easier to maintain order with the necessary documents at your disposition to answer questions throughout the process about previous stages, what has been done and how much has been done of it. Keeping a well organized document and sharing progress with the client is a key process to Agile methodology, and keeping momentum strong.
Introducing new members to your team
It’s easier to help a new member of your team in the understanding of your working process when you have previous documents, because then they have something to look at and you won’t have to keep reminding him of essential points afterwords. Of course, this won’t eliminate your need for a formal introduction, but later on it will make the need for further questions a lot lesser.
Improving Working Process
Looking back at what was previously done, do you think you’re missing a step? Are you being too unclear and messy at some point? Are there miscommunications among your team members from one stage of the process to the other? A document can help you answer all of these.
What, then, should this document include?
It actually depends on the type of project you’re working on and the steps that project includes. IncWorx, as I'm sure you've realized, specializes in SharePoint User Experience Design and Implementation. Considering, thought, the hypothetical scenario that you’ll be working on an implementation from scratch, the document should ideally include the following:
Project introduction
Basically, just answering the following questions gets you all the way across:
• Who’s the main client?
• Which is the main objective?
• What is the driving factor of business value?
• What’s the client’s vision of the project?
Written briefly and to-the-point, to have as the background of the whole project.
A user centric experience requires identification of users and user research
This means getting down to creating personas. And of course, the document will consist of all the created profiles after identifying the users and their needs. Having clear and complete persona profiles will support later stages in the design process.
Website content requirements
After deciding on the personas, what should the website have to offer them? Keeping in mind that we have now both, the users’ and the client’s needs documented, we can list requirements as a checklist to be later on verified and revised. There are many ways we can do this in an organized way to suit our needs at the moment.
Concepts to apply
How will these requirements be met? This stage basically answers the question ‘What will we do to meet the previously established requirements?’, considering the issue in terms of user reactions and the concepts to apply in order to generate these reactions.
Information Architecture
A formal or informal diagram of the information architecture map is a must, as it’ll be an important guide throughout the later stages of the design process.
Interactions
This stage in the documentation process includes basic diagrams of the main interactions that will be applied in your website. Such interactions might include basic error notification, success notification, link behavior, drag and drop interaction behavior, among others. Make sure to have your feedback clear on each interaction diagram.
Navigation
Navigation design for a SharePoint Implementation is based on two methods; one consists of working with application diagrams to map your whole navigation system - or, based on client comfort level - with site maps.
Concept designs and prototypes
It is important not just to include the final, clean wire-frame, but also some of the sketchy beginning ones, the ones in lower qualities with representative elements and some of the rejected ideas to illustrate your process.
Usability testing on prototypes
Trying to keep it as lean as possible, usability documentation can include the final results and statistics. You may include the scripts you created as guides for you and your team if you tested it through focus groups or personal interviews, too. But you may have tested using a device such as eye-tracking or mouse-tracking, in which case you could just include the resulting generated maps.
Development plan and technical specifications
With the previous documentation and research, development decisions can be made. These decisions involve the technologies that will be used to create the application that has been designed, justified by the requirements that need to be met.
Style guidelines and patterns
The final specifications about colors, indentations, images, among others. These have to be well established and justified, too, in order to serve as a guide throughout the development process to maintain the visual design standards.
In Summary
As it may seem a "project bible" is in the making, it doesn't need to get out of control. The project and client dictate the right amount of documentation. All in all, at IncWorx Consulting we firmly believe is a holistic approach to Implementing SharePoint 2010 within your organization - and documentation is one that we recommend staffing and including in your next project! It helps keep some order in the messy chaos that creative work generates.
IncWorx wants to be your SharePoint Partner. Our Creative Resources are available and ready to talk to you about creating a unique SharePoint User Experience.
Give us an opportunity to show you how we can help your organization get the most out of your SharePoint Deployment.
More About the Author
David Jelinek
National Creative & Marketing Director
Email: djelinek@incworx.com
Phone: 630.404.9413
More About IncWorx - Visit our Website
IncWorx Consulting is the premier consulting company for SharePoint, we service clients in: Chicago, Indianapolis, Minneapolis, Cleveland, New York, Houston, Topeka, Milwaukee, San Antonio, San Diego, Dallas, Houston, Austin, Tampa, Orlando, Boston, NYC, San Diego and Los Angeles.
We specialize in SharePoint and have invested significant time and resources into our SharePoint practice. We take a holistic approach from inception to delivery which provides the best possible outcome for our clients.
Rodriguez, Pamela. "UX Project Documentation: Answering Why, What and How." Weblog post. UX Booth. UX Booth, 14 Dec. 2010. Web. 3 Jan. 2011. <http://www.uxbooth.com/blog/ux-project-documentation-answering-why-what-and-how/>.
Powered by Compendium
Comments for SharePoint 2010 User Experience Project Documentation: Why, What and How