SharePoint Health Check-Up can improve stability and performance of your SharePoint
SharePoint Managed Services to improve system reliability.
SharePoint is an amazing tool for building apps. When Microsoft first announced it in 1999 as "Tahoe" (its pre-release name), it was a breakthrough. Now we can use only a browser to develop complex business applications, saving you development and debugging time. Its very agile prototyping can lead to skipping design steps. However garbage in, garbage out is still a valid idea for computers and SharePoint apps. We're talking complex business apps that do staff performance review or onboarding
where legal issues can result from sloppy code.
We all want a repeatable methodology for application development! It should be comprehensive but as simple as possible. So including usability testing from the beginning of the app development cycle, and through every phase saves redevelopment.
The point of involving end users or usability testing at every phase is to save expensive rework at the end of the project and to create an app that users are happy to use, find easy to learn, and use over the long term.
For years the waterfall design process was standard. It proceeds through sequential phases, with milestones as transition and assessment points; and assumes that each previous step is complete before the next phase begins. In contrast, our spiral design process is iterative and cyclical, allows for more creativity, and makes it easier to make changes as we progress. In the spiral design process, we can be in different phases for different functional areas of the app. This method lends itself easily to the user-centered design approach to app development.
1.) Envisioning, 2.) Planning, 3.) Design & Developing, 4.) Stabilizing, and 5.) Preparing for the Next Version.
1. Observe & Envisioning Phase
The envisioning phase of app development is where you define the goals and scope of the app. In this phase, a vision statement, design goals, risk assessment, and project structure are produced. The following usability activities are done during the envisioning phase.
Research involves observing a user doing whatever it is that lets you get closest to an activity. If you haven't decided what you will build yet, but we think a market opportunity exists, we use contextual research to explore the activity. Find out what we can help the user do and how easy it will be to implement it. Don't look for specific features; rather, look for design opportunities.
This provides focus for apps and considers an understanding of what people are doing, how they are doing it, and the problems or obstacles they face. Contextual research works best when you have a cross-disciplinary team working on contextual research led by a usability engineer.
Competitive usability testing sets quantitative usability goals for the app—speed of task completion, number of errors per task, and so on. This results in quantitative measures of success, even if your competition is a manual process you are automating. Competitive testing is often done in conjunction with competitor evaluation, for similar apps. Usability testing is more concerned with task performance using those features.
Competitive testing might not seem appropriate for internal apps. However, if you think about it, we are also competing with our own previous version of an app or process. Internal apps might be competing with a manual process—the app must be more efficient and better than the existing process.
One way to do competitive testing is to conduct a study that compares the performance of competing apps. For example, a benchmark study of other vendor apps.
Know your users! Do everything you can to understand the characteristics of your users. Consider how support calls might decrease if you build your app based on the characteristics of the end users of your app. Imagine that your users find the app easy to use and it contains the features they need. Ask yourself, "What are the relevant characteristics of my users for the apps I am going to build?" For example:
You can gain some of this information through contextual research. For example, you can observe a few people to develop assumptions and then validate your assumptions through a survey or a sampling. Your Human Resources or training department might have relevant information; for example, how much training new employees receive.
2. Conceptualize & Planning Phase
The planning phase is where the first real designing takes place. In this phase early user interface ideas are created in prototype form, drawing on the knowledge uncovered during the envisioning phase. A prototype can be anything from cards describing concepts or functions, simple paper sketches of screens, screens printed on paper, online versions created in a balsamiq mockups with limited interactivity (also called click-throughs), Most of the time, the more fidelity a prototype has, the less likely a user is to suggest major changes, and so it's worth the effort.
Depending on what app we are designing, you might do some or all of the activities described below. If you spend the time doing these tasks in the planning phase with a prototype, you should encounter far fewer usability problems during the developing phase.
Create your own user scenarios that list what typical users for your app can and cannot do. With user scenarios, you create a "story" about how your users use the software you're designing based on high-level design decisions from your earlier contextual research and user/audience analysis. These scenarios can be storyboards, simple flowcharts, or simply narrative text. An elaborate form of user scenario is the "day-in-the-life". This type of persona imaging shows actors as "users" interacting with a simulated app during their daily activities. User scenarios lead into the more specific details you look for in task analysis.
Task analysis determines how a task will be performed in the app. You must do this before you can write a design specification. It is important to use task analysis to determine if the tasks you are planning to support actually reflect reality. Analyze a task for fidelity. As far as the attributes of the app, how complete is the task? Analyzing for fidelity can either mean looking at everything the user must do to complete one task or a surface-level look at everything a user must do through all tasks or features. Don't worry about being exhaustive—focus on the essentials.
Some questions and activities to consider:
Heuristic evaluations involve a small set of users who look at the app and judge it based on basic usability principles. Heuristic evaluations allow you to find and fix usability problems throughout the iterative app design process. If you fix the problems as you go along, you will save work later when logic changes are more difficult.
Heuristic evaluation consists of:
A cognitive walkthrough means carefully reviewing the number and type of steps the interface requires the user to go through to accomplish a task, including those the user has to do in his or her head. What you want to focus on is what users have to recall or what they have to calculate—cognitive tasks that can make your app either easy or difficult to learn and use. The cognitive walkthrough helps you identify potential usability problems as well as holes in your specifications!
To do a cognitive walkthrough you need four things:
Given this information the evaluators step through the action sequence (item 3 above) to determine if users can be reasonably expected to perform those steps.
GOMS is a method for describing a task and the user's knowledge of how to perform the task in terms of Goals, Operators, Methods, and Selection rules.
A GOMS model consists of descriptions of methods necessary to accomplish desired goals. The methods are steps consisting of operators that the user performs. If more than one method is available to accomplish a goal, then selection rules are used to decide the appropriate method in this circumstance.
Card sorting is one usability technique used early in this phase to understand users' conceptual models of information. The basic task during a card sort is for participants to organize cards with a description on them into piles with items that belong together. After creating the piles, the participants can also generate names, labels, or descriptions for the piles they create.
Card sorting is used to:
Iterative usability testing of a prototype design provides another valuable way early in the app cycle to find out how easy or difficult users find the interface to use. Making changes at this phase is much easier and much less expensive than waiting until after development has started.
The amount of data you can collect in a usability lab from a prototype depends on the robustness of the prototype. For paper prototype testing, the usability engineer is the computer and sits with the user during the test.
In many cases rigorous usability testing is overkill. During the prototyping phase, you can still conduct valid usability testing using simplified methods, often called "discount" usability testing.
An iterative usability test incorporates:
3. Design & Develop Phase
The developing phase is where the app is implemented in code (event handlers, workflows, CSS, JS). During this phase you can now begin usability testing early builds of the actual app. You might still be working with prototypes quite a bit in this phase, but more of the app will be finished as time passes. Not all of the features will be in the development phase at the same time so you might switch back and forth from prototypes to real code. Ideally, you will be able to spend most of your time polishing, having worked out the major problems in the prototyping phase.
Having users test a live code version might be useful in discovering problems specific to using the app. These problems usually have less to do with conceptual issues than with the design. They typically involve rather low-level interaction issues such as selecting items and dynamic actions that are only available with the actual app. For most aspects of your app, live code doesn't necessarily have more fidelity than a paper or another prototype, so don't delay usability testing until you have live code.
In the developing phase, you can conduct usability lab testing, similar to the iterative usability testing in the planning phase. However, since more of the app is complete, you can measure more tasks. You might still use a mockup, or you might work with a slightly changed build. As time goes on, and more and more of the app is finished, it will feel less like a prototype. However, the problem with testing with a "finished" app is that since so much work has been done and so little time is left, you should not expect too much to change based on your findings. As part of this task you might also ask focus groups (our clients willing to beta test).
4. Construct & Stabilize Phase
The stabilizing phase occurs when development ends and bugs are fixed to create a stable app. The usability focus in this phase is fine-tuning. New features and expensive usability enhancements should be documented enhancements for the next version.
Benchmark usability testing is similar to integration testing in Quality Assurance. The goal of a benchmark test is to provide reliable quantitative data on the usability of an app across the top tasks users will want to accomplish. The object of these tests is less to identify bugs and more to assess the state of the app's usability.
For a benchmark test, look at the features of an app and break the features down task by task. In the stabilizing phase, especially for a complex app, you will not be able to make changes to the UI that improve every single task. Ideally you want to determine what the top tasks are and make sure they are the most usable. The lower priority tasks can be less usable and go on the list to be worked on for a later version.
5. Preparing for the Next Version
Think of this phase as starting the process over for version NEXT. You go through many of the same tasks you did in the Envisioning and Planning phases. For example, you will conduct:
Mention this post and we'll send you a white paper on all of our customizable SharePoint apps!