Product Blogs

• The User’s Edge — The official blog of The Raiser’s Edge
• The Ledger — The official blog of The Financial Edge
• The Spotlight — The official blog of The Patron Edge
• The Book Bag — Blackbaud’s school software blog

Personal Blogs

• Connections — Steve MacLaughlin, Director of Internet Solutions
• Navigating the Fundraising Universe — Jim Bush, Enterprise Bus. Architect
• Webby Things — Chad Norman, Manager of Internet Marketing

Corporate Blogs

• From the Doc Side — The Product Documentation Team Blog
• Blackbaud News — Up-to-date Blackbaud News

Industry Blogs

• NetWits — Internet marketing, communication, tools, and technology

.

The User’s Edge: The Official Blog of the Raiser’s Edge
The Ledger: The Official Blog of The Financial Edge
The Spotlight: The Official Blog of The Patron Edge

There are also a couple of personal blogs: Steve MacLaughlin’s Connections and my own Webby Things. The infamous Jim Bush is next, along with a few more brave souls we’re coaxing out of the ‘baud. Stay tuned for more, or just subscribe to Blackbaud Blogs (rss) and let us come to you.

But a huge part of facilitating processes involves communication among people and departments. I’m wondering what we can do to better allow users to communicate with each other through our products? And where would this type of functionality be most useful? We’ve already taken steps in this direction in specific areas - Major Giving cultivation, for example, where we’re looking to improve the ability of fundraisers and their managers to communicate progress and status on their prospects. But I think this is an area we can explore further and really take advantage of some of the newer tools available to us.

It seems like there are some key characteristics of situations where in-product collaboration would be most useful:

• The specific context lends itself to questions, clarification, and a general discourse on the value, interpretation or significance of what is being shown. Obviously, part of this characteristic includes the need for multiple people to be interested in the context.
• There is some value in being able to capture this conversation in a centralized place and in close proximity to the subject of discussion.
• The relationship and proximity of the people involved encourages online communication. People who share a cube are less likely to use something like this than are people who are spread across departments and separated by some distance. Probably more value to larger organizations than in smaller ones.

Examples where in-app collaboration might be useful include:

• KPI dashboards and other reports - this type of data display can immediately provoke questions, clarification and discussion around its meaning and implications. Why is this trend happening? Can we expect to make this goal? What events may effect the future of this data? An ongoing discourse of this kind if very healthy for an organization, and could further enrich the usefulness of this type of display.
• Major giving cultivation - all of the intricacies involved in cultivating a prospect are often difficult to capture in a set of pre-defined fields. Ongoing conversations about the propensity and inclination of prospects could potentially be managed through in-product collaboration features.
• Event management - planning large events takes a huge amount of communication, and decisions are made quickly constantly throughout the lead-up to the event. Centralized management and documentation of the decision-making process could help ensure that decisions are communicated clearly and people don’t spend time repeating past discussions.

Relative to other more prescriptive features, in-product collaboration solves an “ill structured” business problem. In some ways, we may not know how (or if) users would employ it until it is in actual operation. How might this type of feature fit into your organization? Do you see opportunities for improving communication through in-product collaboration?

Here’s the story. Over the past several months I have made small gifts ($25) to a number of CLIENT organizations that I worked with during the same period. To be exact, I made 10 gifts of $25 each: seven made online, two sent by mail, and one handed to someone at the organization while I was onsite. These gifts represented my first donations to these particular organizations, and were undesignated so that the money could be used where it was most needed.

So far, so good, right? Here is where it gets interesting. Take a guess at how many acknowledgments I received for the 10 gifts I made. It’s less than half – actually, it’s way less than half. TWO! Two thank yous out of 10 gifts made! One from an online gift, and one from a mailed gift. And, yes, every organization had my mailing address and I did not indicate anywhere that I did not want to be acknowledged for my gift. Don’t blame this on me!

Here’s a little more insight into my experiment. I have followed up with most of these organizations over the past month, starting with the two that did send me thank yous. Both of these organizations were a little surprised when I called to thank for thanking me. Most of my contacts at organizations that didn’t thank me were themselves surprised that I had not received a thank you, and promised to follow up and to be sure that I was thanked (and still not one thank you as of January 22 – so now they have had TWO opportunities to thank me and have failed to do so both times…) And, keep in mind – these were all Raiser’s Edge clients. There is absolutely no excuse for not acknowledging donors.

What surprised me most, however, was a comment my contact from one of these organizations made in regards to why I had not received an acknowledgment. She said, “It’s our policy to not acknowledge gifts under $250. We only acknowledge gifts that are over $250.” She did go on to say more, but I honestly didn’t hear a thing she said after that. They really have a policy about NOT thanking some donors?!?

This whole thing has me very puzzled. I would have understood if one or two organizations had neglected to thank me, but eight out of ten? Was my sample not representative of the industry? Plus, these were Raiser’s Edge clients, so I know they have the infrastructure to efficiently acknowledge gifts – it’s just as easy to run 100 thank yous as it is to run 10, right? Did they think I didn’t need an acknowledgment because I work for a company that is one of their vendors? Or, are these organizations just out of touch with their missions?

I didn’t make these gifts just as an experiment. I also genuinely believe in what these organizations do (I would share with you what these orgs do, but it would be too easy to figure out who they are). And, to be honest, yes, I was personally testing them. How they handle a small gift tells me a lot about how accountable they are as an organization. Can I trust them to use my money in the way I intended? If I worry about what they did with my $25, I surely am not willing to give them more money.

Loyalty is a two-way street to me. I want to give to an organization that I know cares deeply about the mission they serve, and also about me as a supporter of their mission. I get asked for money all the time, and I have my own rules about who I give to: your mission has to touch me personally, you have to show me that my dollars (no matter how big or small) can make a difference, and you have to treat me like I am part of the team. What are you doing with my (and everyone else’s) money? How is this helping you accomplish your mission? Loyalty is a two-way street to me.

So, am I expecting too much? Was this homemade experiment skewed in some way? Should I be as puzzled about the outcome as I am? Or, should I accept this as the state of fundraising today? I would love to hear your thoughts!

These were existing RE users, so our hope is that they were just reacting to a change in the pattern they’ve grown accustomed to. But “they’ll get used to it” always makes designers really uneasy. Will they? How can we be sure this was an issue of familiarity and not a fundamental design flaw?

We’ll continue to test this issue with both RE and non-RE users, but I think this highlights the reality of user feedback and decision making in the design process. User input is one of several tools designers have at their disposal to help make the tough decisions, including design patterns, design principles, usability heuristics and personal experience. All of these are invaluable resources for informing the design process, but rarely do they make design decisions crystal clear. They are all very open to interpretation. In the end, it is still up to individual decision makers to make the “right” call based on the information they have.

For this reason, the real power in user-centered design comes not from a few usability tests and design heuristics, but from the development of a culture that puts a priority on user experience and encourages an ongoing, iterative process of feedback and refinement. This process doesn’t end when a product is released - existing features should be constantly re-evaluated and every new customer treated as another opportunity to evaluate your design decisions. Through these ‘layers,’ the experience becomes more and more refined:

When your decision makers are making user-informed, skillful design decisions, the difference between these levels are minimized. The process is then allowed to focus primarily on adding efficiency and smoothing out rough edges while functionality is gradually expanded. And when changes are required, this isn’t seen as a failure, but as a natural part of the design process.

Paul Crowder (the dev) has been working on implementing platform-level support for KPIs (Key Performance Indicators) in our upcoming Infinity application platform. KPIs will be featured throughout future applications built on the platform (Galileo, RE8, Bullseye etc.) Apologies for all the code names, we’ll cover those in a future post.

What are KPIs?

KPIs are quantifiable measurements that reflect the health of the organization. By quickly scanning an organization’s KPIs one should be able to get a solid idea on how things are tracking against the defined business goals. Some examples might be:

• Response Rate for a direct mail segment
• Number of gifts per day
• Avg days to close a major gift
• Gifts This Month
• Cost Per Dollar Raised

Those are just a few samples, but each one represents a single value that could be calculated and compared vs. an established goal.

Infinity’s KPI Platform

Editing a KPI Definition

Infinity’s base platform support provides the following for KPIs:

• A framework and UI for establishing, securing, and managing KPIs.
• A way to express a goal for a KPI.
• The ability to define warning and alert zones for a KPI as it progresses toward or deviates from it’s goal.
• An automated process to calculate KPI values and cache those values for quick rendering at a later time.
• A mechanism to back-calculate KPI values to establish historical trends.
• RSS support for KPI values so they can be monitored without running the application and logging in.
• A personal dashboard that can be customized by an end user to display the most important and relevant KPIs as the user sees fit.
• The ability to view the dashboard outside the application from any web browser without having to log in and navigate the application (assuming the user is authenticated).
• A stock set of KPI calculations “in the box”.
• Advanced support for creating custom KPIs using an open, extensible XML specification. (you’ll be hearing a lot about “specs” in the Infinity platform as I discuss it in future posts…)

A KPI Dashboard in “Galileo”

An Infinity-powered application presents a user interface that allows organizations to define their KPIs and have the system constantly calculate them based on the data as it flows in. Typically, you would sit down with leaders in the organization, agree on your KPIs and goals and then setup the KPIs in the system using a very simple user interface. There is even support for back-dating them so you can have a look at quantifiable results from the past, which can be a useful benchmark from which to build on as you define your unique set of KPIs and goals. Then the fun starts.

Once the KPIs have been defined they can be featured wherever you like inside and (here’s the killer part) *outside* the system! Infinity support syndicating KPIs and alert mechanisms via auto-generated web pages, RSS feeds (which can be consumed directly by IE7 and feature rich support for sorting and filtering), and even via directly accessible AJAX-friendly web service end points! The key point here, is since we are building all this stuff using standard open technologies like XML and Web Services, there is simply an explosion of interoperability and reach scenarios. What “the Pauls” showed me today was a great example of leveraging that power. So, let’s talk about what they showed me…

Technology Converges on the Windows Vista Sidebar

Windows Vista has added a really nice feature for displaying graphical gadgets directly on what is referred to as the sidebar. Its a nice unobtrusive way to have important information featured on the the desktop. For example there is a little weather gadget that gives a graphical cue and some other info about the weather conditions at a given location. I guess you could say a Sun is a good KPI and a Rain Cloud a bad one. Interestingly the sidebar supports using standard Dynamic HTML and JavaScript to build custom gadgets. When the team was discussing scenarios we wanted to support for KPI reach, we all got excited about the possibilities here. Remember when I mentioned that Infinity exposes it’s KPI data as an AJAX-callable endpoint? Well, add one part Vista, a little JavaScript/AJAX to call Infinity, some Dynamic HTML to present the user interface and whammo, you have KPIs on the desktop. Sure, when we release this it will look prettier (the current rendering is placeholder art) but I think it’s pretty cool.

The true payoff of using open, standard technologies really is exciting. When I think of all the mash up scenarios we’ll be poised to support it puts a smile on my face. And if all this technology helps you improve the reach of information, whether it be to your boss, your board, or even your constituency I hope you’ll be smiling too.

We’ve been having an ongoing discussion in Blackbaud Products around customer expectations for communication and how different approaches can help meet these expectations. The discussion has a decidedly Web2.0 bent to it. There’s a long list of needs, including:

• Customers need to get ‘help’ on how to use a product
• Customers need to give suggestions on product features
  • Customers need to know that someone is reading their suggestions
  • Customers and Blackbaud need suggestions to be prioritized
  • Blackbaud needs clarification on suggestions
  • Suggestions need a status - customers need to know if and when and how a suggestion will be met
• Customers need to know everything about new releases and how they will affect their organization
• Blackbaud needs ongoing feedback on requirements and design
• [fill in your needs here]…

Lou Attanasi tells us about the early days at Blackbaud when every suggestion received a hand written ‘thank you’ letter acknowledging the idea. One or two people were employed exclusively for this purpose. As Blackbaud grew, of course it became impossible to keep up with this practice, but new technologies and techniques make it possible for us to re-invigorate this level of personal attention in a much more manageable fashion.

Rather than one person writing thank you letters, we can now have multiple designers responding and asking questions about customer suggestions. Rather than a product manager prioritizing suggestions behind closed doors, it can be done in public, in conjunction with customers and business analysts. Rather than calling 5 customers to ask them their opinion on a new feature, we can post the feature publicly and get feedback from 500.

The really tricky part comes when we start thinking about how to create and structure channels of communication in such a way that the messages are easily managed and the feedback loop is strongly supported. How do we harness the strengths of each tool so as to make the process overall that much more robust? How do we make sure we’re providing ways to communicate and not just more places to put thoughts that are never acknowledged? These are the questions we must answer in order to meet these evolving expectations.

The key Web2.0 message that customers are sending to businesses in all industries is that there are no more excuses (Customer2.0?). There are no excuses for not talking to us and there are no excuses for not listening to us. Organizations that ignore this message will quickly find themselves stuck in the mud and passed by competitors who truly connect with their customers.

• quantitative (lose 20 pounds!) or qualitative (eat healthier!)
• subjective (be a better person!) or objective (spend 10 hours a month helping out my favorite charity!)
• personal (appreciate the little things more!) or altruistic (make the world a better place!)

…but they are things that challenge us because they challenge our ability to overcome our limitations, our conditioning and our environment.

Of course, I’ve got my list of personal resolutions…..drop 20 pounds, finish the Cooper River Bridge Run in under 50 minutes, and complete a lengthy list of home improvement projects….just to name a few. However, I thought it would be an interesting exercise to try and come up with a New Year’s Resolution that has an impact on our Products team at Blackbaud and, by extension, the products we deliver. While surfing the web looking for some ideas, most of what I found centered on resolutions like “write more reusable code”, “comply with web standards” or “do more usability testing”; all worthwhile goals, but they didn’t capture my imagination or feel like what I was looking for.

Eventually, I came across an article discussing New Year’s Resolutions and “Deficit Thinking”. The article defines Deficit Thinking as “an ingrained habit of focusing on gaps and weaknesses instead of what’s working” and goes on to talk about the value in avoiding it and provides some strategies to help avoid it. The article itself may be a little too Stuart Smalley and doesn’t specifically apply the concept of Deficit Thinking to software development. However, the basic definition of the comment did strike a chord with me. Much of what we do in developing software necessarily involves Deficit Thinking;

• Product Managers and Business Analysts study gaps between what our products do and what our clients need them to do (or what our competitor’s products do!).
• Developers work to ensure that all of the product requirements are satisfied in the code they write and try and figure out why their code won’t compile or pass unit tests.
• Quality Assurance Engineers demonstrate the creativity of Van Gogh (for the QA people out there, that was a compliment, not a comment on your mental stability!) in devising test plans designed to identify gaps between what the product does and what the Business Analysts said it should do.
• Usability Engineers exhaustively test our products for ease of use and collect reams of data that point out where they are substandard.

It’s not a stretch to say that a software development team simply can not function without a culture deeply rooted in Deficit Thinking. That said, I think that providing truly compelling products and solutions to our clients requires an ability and willingness to balance this mindset with one that keenly recognizes how and where our product features provide value to our clients and seeks opportunities to build on that value or apply that value to new challenges. This type of “Opportunity Thinking” (for lack of a better term) provides a valuable complement to skills we all bring to the process of building products by focusing that process on maximizing the value we provide to our clients rather than towards satisfying a list of requirements.

So, there you have it, my New Year’s Resolution for Blackbaud products:

To balance “Deficit Thinking” with “Opportunity Thinking” by recognizing the value that our products provide and thinking of new ways to enhance that value and apply it to the challenges our clients face.

We’ve started this site to give our employees a platform to sound off on what they know best: technology, nonprofits, business, and Blackbaud itself. There are a few of us here who have wanted to blog for years, and now we’ll have our chance. We look forward to discussing topics with you, so please leave some comments!

We would love to hear what you think, so if you have a question or comment just let us know.