Sometimes accurately identifying and defining your problem is the crucial step in building an effective solution. Applying our experience from hundreds of cases, we start by asking the right questions. We don’t claim to be the expert in your subject matter, but we are the experts at finding out what your experts know so it can be used to improve the performance of others.
During the early stages of the analysis, we look carefully at the audience for your product; but we don’t stop there. We also consider the situations they will encounter when using your product. Performance can only be improved if you know what your users are performing!
The second critical step in the analysis is looking in detail at your current information content (if any exists). How is it structured? What can be generalized? What are the common themes? This sets us up for the design of the information architecture that will provide the host structure for improved access to your data.
Let’s take a look at how we go about this analysis.
Discover Requirements
The requirements discovery is where we find out what you want, even if you don’t know it yourself. Sometimes the solution doesn’t become apparent until you see what the possibilities are. Here are some of the important things we’ll focus on:
- Your processes: The way you currently do business. What makes your operation valuable?
- Your goals and objectives: What do you hope your audience will come away with? In a training application, these would be your Learning Objectives.
- Opportunities for improving the way you work: Captures the knowledge of your best Subject Matter Experts by working directly with them to exact, capture, and encapsulate what they think and what they do. Sometimes they do it without thinking, but we make them think about it anyway.
- Technology insertion: We look for ways to automate, propagate, integrate or substantiate; virtualize, hybridize, mobilize or catch-your-eyes. But we apply technology where it’s needed; we do not have a particular solution that is looking for a problem.
Generate Concept
With an objective requirements discovery comes the opportunity to muse about possible ways to structure a solution, be it interactive game-based training, some form of performance support, or a straight technical documentation product. We like to bring in designers and developers at this stage to gather ideas from several different points of view. What story could we tell? What technology could we apply?
Our process for solution development spirals; ideas spawn concepts, which spawn new ideas. We climb the spiral staircase with you, and we prefer to bring along key stakeholders at strategic points in the analysis. One of our important tools for doing this is the wireframe. Wireframes walk the narrow line where you can explore a visual concept but not go to great expense to render it. Sometimes we call them ugly wireframes to remind our designers not to go too far in exploring concepts until we settle on the one that will define the solution.
Assemble Content
The job of the analyst doesn’t end with the idea that will solve your problem. In most cases, we still have work to do and in some cases we still have a lot of work to do. Analysts are responsible for collecting the content that will ultimately reside in, and define the behavior of, your interactive product. We take great care to get the technical details right; we often rely on your SMEs to provide the basics, and we add value by tailoring the content to fit seamlessly with the application.
During the content collection phase, our Analysts become your advocates by documenting and relaying technical details to the design and development team. The Analyst takes responsibility to ensure that the animation of sonar reflections traveling in deep water complies with the laws of physics; and that the switches on the simulated control panel in a fighter jet operate like the switches in the cockpit; and that the narration introducing the features of your new corporate email rollout tell your employees something they want to know.