Coy Yonce

Designing Business Intelligence: The Brainstorm

cyonce — Fri, 04 May 2012 05:35:44 +0000

When it comes to deploying a Business Intelligence solution, there are many contexts by which one could consider their deployment a success. For example, if the system is up and running 99.9% of the time, this could be considered a success. Business users are able to get to information that exists in the system. Another example is whether the system provides adequate pre-built content that is easy to find and easy to understand. This is surely a success as the users are able to not only get to the information that they need quickly, but it is actually useful. Obviously, there are many other success factors that should be considered; however, that is not the point of this post.

So, you may ask, what is the point? One of the things that I am interested in is the design of solutions based upon the needs of the community. Over the next few weeks, I will be writing on the topic of designing BI solutions and the content that will be delivered via those solutions. The overarching theme of the initial part of this series is ‘brainstorming’. This does not necessarily mean amongst a group of people. It could be an individual brainstorming; however, the greatest benefit in BI design will come from sharing your ideas, getting feedback, and improving upon those ideas. As such, these brainstorming techniques will work for both individuals and groups.

On to the first topic….

Persona

As defined in C.G. Jung’s study of archetypes, the persona “represents all of the different social masks that we wear among different groups and situations.” In the study of user experience, the definition of a persona does not differ significantly. It represents the different groups that individuals represent when interacting with various products or services. The idea of a persona exists regardless of the “thing” with which one is interacting. We can apply this to designing a business intelligence solution as means of defining the different types of people (a.k.a., roles) that will be leveraging that solution.

This is possible to achieve individually; however, we’ll get to that in another post. I’d first like to talk about the definition of personas by a group. This can be done by getting the group into a Persona Workshop. The individuals who take part in the workshop should be chosen carefully as representatives of the potential user population. Likely, these are the same individuals who either will take part or have taken part in the selection of the purchased BI products. In addition, it is important that the chosen participants are vocal, but reasonable members of the user population. Special care should be taken to not introduce “toxic” members into the group. Everyone will have their own agenda, but should also be willing to listen to and reasonably consider the viewpoint and needs of another group.

Once you have chosen the members of your group, you then should have an initial meeting to introduce the concept of the persona workshop. The objective with the workshop is to walk away from it with everyone understanding each of the user types (or personas) who will be interacting with the BI deployment. This understanding should not only include the type of user, but the needs of the user type in terms of type of information, how they want to access information, their informational goals, and their criteria for success. In addition, any assertions that intend to be made about a specific persona should have relevant data behind it. Everyone should walk away from this initial meeting with a solid understand of their expectations with regards to representing their department within the persona workshop.

When scheduling the persona workshop, you should allocate two full days with a lunch breaks. Be sure to include frequent breaks during each half as well. This will keep your audience fresh and ready to participate. Perhaps even doing some exercise periodically or even bringing in a yoga instructor for a 30 minute session would help keep people sharp as well.

The actual running of the workshop should include the following steps:

Restatement of the objective for the workshop with everyone’s agreement to participate fully. This means no computers, no emails, no phone calls, etc…if they can absolutely avoid it. Any interruptions will not only take them out of the meeting, but can disrupt the process for everyone.
Restatement of the fact that, where possible, assertions about a persona should be accompanied with representative and relevant data. For example, if I were to state that a user on a mobile device expects 2 second respond time when downloading an image, then I should be prepared with data to validate this fact by showing website abandonment numbers from mobile users.
Start the meat of the workshop with an exercise that allows everyone to define a type of user (a.k.a., persona) and some assumptions, expected goals, or actions that the user will perform with the BI deployment. For example, I could say that a user of Evernote, the product in which I’m writing this blog post, expects to publish a post directly to a target blogging platform. I could also say that, as a technical user, I am willing to download add-ons to achieve this purpose. The first of these examples defines an action that I expect to take within Evernote. The second example defines an assumption about me as a type of user.
After this exercise, you should give the group a break of some sort. If it’s not time for lunch, then perhaps some exercise as well.
Once the break is over, the next exercise should begin. This exercise is used to allow for better definition for each of the personas that arose during the first exercise. It is possible that new personas will arise as part of this exercise as well. Everyone should be provided with sticky notes upon which they will write a persona and something about that persona – specifically, something that the persona wants to achieve with the deployment or a problem that they may have with the deployment. This exercise should last no longer than 30 minutes.
You should allocate 2 hours for the next exercise. The objective for this exercise is to have everyone read out their sticky notes and then to stick them on the wall into groups based on their similarities. Once all of the sticky notes have been placed on the wall, ask everyone to get up and reviewing them to determine if they are in the correct groups. This part of the exercise should cause much discussion, some persona movement, perhaps some redefinition, and the creation of of new groupings. In the end, you will have themes that have developed based upon the groups. These themes and the associated sticky note text should be recorded digitally and passed out to the participants. The diagrams of themes should remain on the wall until the end of the persona workshop. This allows for quick reference of persona needs by everyone whom is participating.
Another break should follow this exercise. Don’t forget some physical activity.
The next exercise is geared towards assigning data to assertions about a persona within the theme diagram. Each participant should be provided with another stack of sticky notes. On these sticky notes, everyone should write a hard fact based on research about how a persona would want to access information, challenges that the persona has with BI deployments, the types of information that the persona needs, their goals for the BI deployment, and their criteria for success. For example, one could write: “According to Gartner, 60% of information designers would prefer a desktop tool versus a web-based tool.” These data points should come from credible sources – whether they be market sources or individuals within the organization. This exercise should take about 30 minutes.
The next exercise is similar to #6 above in that everyone will read their sticky notes and then place it over the persona that is affected by that data point. For those personas with a large number of data points attached them are good. This means that you understand the persona well and are able to serve the needs of the user if you design the system correctly. For those personas with little to no data points attached, there will be a need to research this persona further to validate assumptions. For those data points that have lots of related data points, but little to no personas, it will be necessary to further determine how the system can fit the needs of those data points – thereby creating opportunity for addressing other persona needs.
With the data points attached to the themes, you can now start selecting those personas on which you should focus your efforts. At this point, you should go around the room and ask everyone to vote on their favorite personas. By the end of the exercise, you should have about 5 or 6 personas mapped out that have a name for the persona and some high level facts about the persona (e.g., basic computer literacy, needs data quickly, does not want to login to get reports, etc…).

With the persona workshop complete, you now have a list of personas that should be used to guide all available interactions, BI content, deployment availability requirements, and key performance indicators to track the success of the deployment. As the personas were agreed upon by representative stakeholders of the deployment, you can use them for reference when attempting to weigh new feature and content requests from the user community against other requests from the same community. The defined personas are a good tool for guiding your BI deployment in the right path towards success.

Do you currently use this model when defining the needs of your BI community? Is there something missing from what I have outlined? I’d love to see your feedback and comments.

Thanks for reading.

Coy

another attempt at creating slopegraphs in crystal reports

cyonce — Mon, 06 Jun 2011 04:49:07 +0000

In my previous post, I presented the slopegraph which Edward Tufte wrote about in his book The Visual Display of Quantitative Information. In that post, I was having some trouble representing a slopegraph using SAP Crystal Reports 2011; however, I think that I have been successful and creating a reasonable representation using SAP Crystal Reports for Enterprise.

I was having some issues with getting the chart labels on the left hand side to line up with the start of the line in each chart. As such, I just stretched the labels to cover the height of the chart and rotated the text to a 90 degree angle. While this is not ideal from a readability standpoint, it is definitely better than the previous example. The line charts do show a pretty good slope. In the example above, it fairly easy to determine how each resort is performing year over year. You can also determine that the Hawaiian Club resort brings in the highest amount of revenue when compared to the other two resorts based upon the fact that it is the first chart in the list. Again, I hid all irrelevant components of each chart so that the line appears to just be part of a table-like display; however, the report itself is created based on groups defined by resort and then a line chart in the Group Header of each group to show year over year change in revenue.

Suggestions for making this better? How does it compare to Tufte’s display and the purpose of a slopegraph?

Coy

my adventure in creating slopegraphs with crystal reports

cyonce — Mon, 06 Jun 2011 04:15:56 +0000

Since seeing Edward Tufte’s post regarding Slopegraphs, I’ve been attempting to create one using SAP Crystal Reports. The benefits of a slopegraph is that they let you compare the relative positioning of one dimension against all others in the same set while also letting you track the performance of an individual dimension from that set over time. To lift a great, but potentially depressing, example from Tufte’s post:

This image shows a slopegraph from Tufte’s post. The slopegraph in this example shows the survival rates of particular cancers. As mentioned above, slopegraphs have the ability to show relative performance of dimensions as well as performance over time of individual dimensions. In the image above, you can see that the table graph shows Prostate cancer has a higher survival rate than Thyroid. Thyroid has a higher survival rate than Testis cancer. So on and so forth. In addition, you can also see that Prostate cancer alone has a better survival rate within 5 years than at 20 years.

Upon seeing the post by Tufte, I realized that this type of graph would be very interesting for monitoring various aspects of business performance. For example, how each product is performing relative to each other and year over year. As such, I have attempted to recreate this type of display in SAP Crystal Reports. Unfortunately, it is not as easy as I would have liked; however, hopefully I can change this in the future as this is a very useful type of information presentation.

As you can see in the image above, I was able to get close while using SAP Crystal Reports 2011. This report uses a group for each cancer type which then has a chart inserted into the group header. I turned off the legend, all borders, all titles, and all gridlines. I turned on the data labels and set the x-axis labels to display on the top rather than the bottom. The problem is that I cannot get the line charts close enough together without reducing the line size so much that it shows virtually no slope whatsoever. The image below shows what happens if I try to get the labels closer together.

Unfortunately, the slope of the line becomes so compressed that it does not really allow for any helpful recognition of a decrease or increase in survival rates. I have, however, been able to successfully list the various cancers in the order of survival rates. I’m still considering possible ways to implement this chart and will post a solution when I have one.

Comments on possible solutions are definitely welcome.

Coy

online demos of business intelligence software

cyonce — Mon, 31 Jan 2011 22:54:54 +0000

As part my role at SAP, I am responsible for researching the activities of competitors when it comes to new product releases, exciting features, and their place in the market versus ours. As such, I’m constantly on the lookout for any online demos or tours of software that is offered by our competitors. I have provided a list of the demos and/or tours that I have found so far during my research today. I will continue to update this list. If you have one that you think should be added, let me know.

IBM

QlikView