The Cost Benefit of User Experience

UI-o-Meter

What are people saying about the last thing you built for them?

I’m doing you a favor today. I’ve written about this subject before, but I’m going to spare you the trouble of searching my blog and I’m going to spare you the accidental navigation (if you’re reading this on a mobile device and trying to scroll) caused by me inserting a bunch of links to previous posts. I’m looking back over my 35-plus years doing systems development and I’m going to summarize the whole thing for you:

The people who use the systems you build deserve the best experience you can give them.

There. That’s it. That’s really all you have to read. If you are wondering how I came to that conclusion or why I’m bringing it up, feel free to continue reading but if you’re content to nod your head and even grudgingly agree with me, well then, off you go.

OK, you stuck around. You know what that means. You’re going to have to read a story.

In 1988, I was in a meeting with my boss, a representative of our underwriting department and one of my better programmers. We were discussing a feature the underwriters wanted in the system we were developing for them. First, a little background (hey, you had your chance to leave):

Nuclear reactors get shut down for stuff like refueling and when they are shut down we charge them less for insurance. The way we do this is by dividing the year into a series of consecutive time intervals, each with its own set of state variables and its own pro-rata premium. Creating a new time interval was a big deal and a difficult process prior to the system we were writing. The designer wanted to make it easy. He wanted the system to show a list of time intervals and let the user highlight one and press the “+” key to insert a new time interval after the highlighted one.

This seemed like a simple request and I agreed to it. The designer wanted more. Since we had never had such an interactive feature in a screen before (this was running under DOS), he wanted us to build a prototype. I told him that wasn’t necessary. I told him that he could see the working element as soon as it was done. He argued that a prototype was necessary because this was a “radical departure from any previous approach.” He also added that he wasn’t sure we could make this. I slammed my hand on the table and said:

If the feature you want can be programmed on a DOS PC, she can build it. We don’t have to prove that to you up front, just let her do her (expletive) job!

After the meeting, the woman came into my office and said:

I appreciate your confidence in me and I like the way you stood up for me, but I don’t actually know how to do that.”

I knew that, but as far as I was concerned, that fact was irrelevant. She could learn. The feature was going to make someone’s job easier and that was worth learning how to do.

Today, as we are in the early days of a new wave of development, I am more convinced than ever that the effort required to build a better user experience is a price worth paying. The math is simple. You build a system once every three to five to seven years but people use that system every single day. Where do you want them to register on the UI-O-Meter?

As an added benefit for those of you who stuck around, I am giving you the answers to a few common problems. Note: I have tested all of these:

We don’t have time to do this” – Give them a choice of waiting a little longer or accepting a second phase to the project.

We can’t do that in SharePoint” – Buy an add-on feature or hire one of those SharePoint whiz-kid consultants who can.

This can’t be done in SharePoint” – Move the process to a different platform.

This would take too many development hours” – Do the math. Development hours vs. hours spent using a crappy system.

If all of those fail, slap your hand on the table and sprinkle in a few bad words.

If you have your own favorite excuse and an alternate way of looking at it, please add your thoughts to the comments.

In Search of Value

Value Hierarchy

Apologies to Maslow

One of the goals that I have maintained throughout my career has been to add value to a process. Long before SharePoint, in fact long before (OK, little before) Microsoft, value was a key requirement in the systems I was building and designing. As a young systems analyst, I remember receiving strange looks from my “customers” when I would ask: “how would that report help you?” I used reports as an example because people always seemed to want more reports than they needed. Once, when I moved a system from one platform to another, I didn’t bother recreating 90% of the reports. I promised to build each one as the need became critical. I only ever recreated about another 5% of the missing reports.

I would get equally strange looks when I would ask my IT colleagues: “how would that add value” or, somewhat more surprising: “how can we build this and be sure we are adding value?

Don’t let me paint too rosy a picture. I’ve built my share of systems that missed the sweet-spot of the target and I’ve left more than a few valuable features laying on the cutting room floor. Systems development has always been affected by drama and budget, in addition to logic.

As I am managing what will likely be my last long-term development effort, I am focusing more than ever on value. I have 3-5 years left to make a start on a new generation of systems, and if I am successful, those systems will be built on a foundation of “adding value to a process.”

I haven’t had much to share on this blog in recent months, but some projects are reaching a point where I can talk about them in generic terms. In most cases, I can’t talk about the work, because I’m not doing it. I can’t talk about the players, because some would rather not be a part of my blog entry. I can’t always talk about the details of the project because legal/accounting/human resources – ‘nuff said. But I can talk about goals and objectives and the way a focus on value has led us to some interesting decisions. Decisions I might not have made back when I started this blog and was bent on using SharePoint whenever possible.

By way of introduction to what I hope is a small series of blog posts (maybe enough to satisfy @Sympmarc’s Saturday addiction) let me share a couple of thoughts on how we got to this point.

Success moves you higher – I am old enough to have participated in systems development projects where the primary goal was to automate transaction processing and save money by eliminating jobs. Oh, we told ourselves that we were improving accuracy and letting people focus on higher-order tasks, but we were also letting them find those tasks at a different company. By the time SharePoint became available, we were way beyond that kind of development and we were looking for ways to use the information we had been gathering. SharePoint offered us a way to move up the hierarchy shown at the top, just a bit.

Failure also moves you higher – The reason I put the “Process Improvement” layer in quotes and in red and with the snarky bit at the end is because it wasn’t always the result. Often, process improvement was a collective bridge too far. Business leaders wanted magical solutions and technical managers and staff couldn’t wait to buy/build/use new toys in pursuit of that magic.

Automating a Business Process

There are times when you can run the table and automate the whole thing. There are also times when that would be a bad idea.

The diagram above illustrates where we sometimes went wrong and how we are correcting those mistakes. Consider the five boxes across the top. Occasionally we have felt that we could automate all of them. In fact, we could. Unfortunately, automated analysis and decisions, by default become arbitrary. A report is on-time, because it is not yet late, or a report is late the moment the time allotted has passed. People on the other hand, understand that a report nearing its due date may be in trouble and people understand that sometimes life gets in the way of an arbitrary due date.

Note: I have been doing this stuff since the ‘70s and yes, I know that systems can be made to be more holistic in nature. However, the effort in building those systems, as well as the effort to maintain those systems is very often too high. Humans are much better at making holistic decisions than machines.

We have recently taken technology out of some steps of a business process that we had previously automated, in order to improve the process. Instead of automating all of the steps, we are focusing on “what information would help humans complete this step easier/faster/with better results?” I put this in the win column because we have the information we need (because we built good solutions in steps one and two). Now, by utilizing SharePoint’s native features, we can provide good information for people to consider in steps three and four. And yes, since nobody wants to do recordkeeping, we will automate that last step.

That’s it for today. I have some stories in mind that build off of this foundation, but those can wait for another day. Maybe not next Saturday, but let’s keep this a Saturday kind of read.

One Stop Shopping Plus Mail Order

imageA few weeks ago, I received an email about an old post about managing a walking contest in SharePoint. Ironically, we are preparing to kick off the 2014 version of that contest in about 2 weeks and once again, we are managing it in SharePoint. I like to use these little side projects to demonstrate what SharePoint can do out-of-the-box. Some might ask “why focus on out-of-the-box? SharePoint can be so much more.

Their question is not quite correct and I am lying just a little bit.

The problem with their question is that “SharePoint can be made to be so much more” but the making can take a lot of time.

The lie that I’ve told is a lie of omission. I didn’t tell you that my box is bigger than Microsoft’s box. My box includes things like HarePoint Workflow Extensions and Nintex Workflows. HarePoint’s extensions add some very cool features to SharePoint Designer workflows and Nintex, well Nintex Workflows are like a slice of SharePoint Heaven here on Earth.

So, truth be told, I like to show people what we can do very quickly in SharePoint with the tools that we have available to us. That’s important for a reason that most IT departments don’t consider often enough.

Sometimes, people don’t ask for things because they think those things will be hard to build or expensive or that they will take too long.

They aren’t trying to save my time or my budget; they’re just trying to avoid being told “no, you can’t have that.

In the 2014 version of our SharePoint-driven walking contest, we have added two new features. Both are aimed at improving the user experience and both came at the request of my new young colleague Stacy. Stacy is not only the architect on this project, she’s the user. She’s managing the walking contest and she’s building the site with some help from me.

For those of you who are unfamiliar with a walking contest, it’s pretty much what you would imagine:

  • Our company is divided into teams.
  • Each person tracks and records their steps each day during the contest.
  • At the end of the contest, the team with the most steps wins a team prize and the person with the overall highest number of steps wins an individual prize.

Stacy wanted to make two improvements to the accounting process for the contest. She wanted to add options for mobile entry and she wanted a dashboard of sorts for reporting progress.

Mobile entry was easy but, again, it uses a few tricks from our bigger box. You can send your entry into a SharePoint Remote Entry library by including the subject line “10-11-2014 8,996” i.e. the date and the number of steps. A SharePoint Designer workflow, aided by HarePoint’s Regular Expression actions parses the subject line and adds the steps to your step count. A second workflow adds your step count to your team’s total.

We could do all the processing in one step, but I like breaking things into small chunks. That is a carryover from my history of coding in Smalltalk, but it’s a good practice for SharePoint. Small workflows are easier to test and they are easier to “debug” since there really isn’t a “debugger” available in SharePoint.

Employees with iPhones can also easily enter their steps via a mobile view of the Steps Entry form. Actually, anybody could do this, but “iPhone” is linked with “easy” because our MaaS360 mobile device management software allows us to push that mobile form through our firewall without the need for a VPN connection (which people hate to make on their phones).

Finally, we needed to build that dashboard, but we decided to make it functional instead of just informative – that’s where the “one stop shopping” comes from. We started with a Web Part Page and we added an Announcement part and an Instructions part in those top-of-the-page whole width zones. Then we added three useful parts. On the left, we have “My Steps” which is a view of the Steps list filtered on the current user. In the center, we added a view of Team Status that shows the current ranking of teams and on the right; we added a simple entry form for steps.

image

I have to admit, this is the first time I have ever put an entry form on a dashboard. It works. Having the entry form on the page makes this page the only thing people actually have to look at. My Steps, My Team and, as I look at my steps and realize that I forgot to enter yesterday’s value, I can do it without leaving the page.

Stacy’s homework assignment is to add a chart to graphically display some of these statistics and to make the page a little prettier. Mine is to start walking.

Liking Nintex

imageSummer is a funny time in most small shops. Projects start and stop as people take time off and attentions get diverted to the periodic crisis or to fill-in for an absent coworker. The downside for someone trying to craft a blog entry at the end of each week is that there isn’t much to work with. Those of you that come here don’t come to hear about the meetings I attended or the fires I put out. The upside is that this post will be short.

One of the interesting things I did this week was to build a SharePoint Workflow using Nintex Workflow. I’ve used Nintex before, but this time, I was teaching someone else how to build a “proper” workflow. The workflow is another part of our Payables process and it allows our accountants to delete a payable that has been submitted and approved for payment. Yeah, sometimes people make mistakes. To prevent someone from making those mistakes worse, this workflow needs to verify that a series of conditions are true. The payable hasimage to be at a specific status. The person running the workflow has to be a member of accounting. A bunch of people have to be notified, the activity has to be logged and we also have to let people know if any of those conditions aren’t met and the workflow has to be stopped.

All of those things can be done using a SharePoint Designer workflow. So, why does the title point out that I like Nintex Workflows? Well, that’s the point of this post. Here is my list of the things I like about Nintex Workflows:

I can add multiple logical conditions into the kick-off point of a single “Run if” block. You can see that illustrated in the image at the top.

I can act against multiple list items in one step. For example, I can say “go find all the allocations that have the same payment_request_ID as this imageitem and delete them.” You can’t do that in SharePoint Designer in SharePoint 2010

I can give an intelligent name to each workflow step. So, the above example step can be called “Delete Allocations” – I like that.

I can copy steps. We need to create a log entry regardless of the imageend-state of the process. Since some of those states cause the workflow to stop, I need to have the “Create Log Entry” step in multiple places which is very easy to do. Copy. Paste. Configure. Done.

I can drag and drop steps in and out of Condition blocks and Impersonation blocks which is very helpful when you realize that you have the right action but that it’s happening in the wrong place.

I can export and import entire workflows. In fairness, I think I can do this in SharePoint Designer, but I have had problems with that process and this worked like magic. I built the basic structure of this workflow from an earlier workflow that lets the person who submitted the payable to delete it before it’s approved.

And, my favorite thing – you work in a browser as opposed to a somewhat finicky, somewhat unpredictable and somewhat predictably bad stand-alone product.

That’s it for today. Not much of a product review, but I think you can understand why I like Nintex. And, I said it in fewer than 600 words.

Proximity Revisited

imageEarly in the life of this blog, I wrote several posts about ‘proximity’ and how important that attribute is to the user experience. I was recently reminded of that fact, and I realized that I my previous examples were too limited.

I was talking about designing a home page or a site page with all the appropriate web parts and without any of the inappropriate web parts. So, if you need to see a task list and a calendar, both of those should be represented on the page, not just sitting over in the quick launch area. Conversely, if you don’t want to have a picture on your site, then you should delete the one of those pretty people.

I also mentioned proximity in association with building dashboards. Having everything that you need being available at a single glance is the key benefit of a dashboard, so I guess my emphasizing proximity wasn’t much of a revelation. I also talked about proximity in terms of business process automation. As our engineers work though the recommendations resulting from their inspections, we tried to give them a view of each recommendation’s life-cycle that was meaningful.

It sounds like I covered all the bases. But, you know that I’ve never written a blog post with less than 250 words, so I must have missed something.

Earlier this year we built a payables process in SharePoint. People can select a vendor, enter a payment request (invoice) and spread that invoice around (allocate) to all the various GL accounts that are affected by it. For example, when we buy a new laptop for someone, we might buy them a case. Those are different types of expenditures.

I have always looked at accounting from a “money in” or “money out” perspective but our accountants seem to be in agreement with my Management Accounting professor – you have to pay attention to stuff like this.

Anyway, the system does all of that stuff reasonably well but there are a few things that the accountants wanted it to do better. Fortunately, one of the women in accounting is also working part-time with my team. One of the things she told me that they want isbetter views of the transactions at all of the various points. They have a view that shows payment requests that are pending, requests that still need someone’s approval, payment requests that are approved but not processes, as well as requests that have been paid and requests that were voided. Seriously, money in / money out works a lot better.

When I sat with her to find out what they wanted, Iimage experienced that old familiar feeling. The presence of that gap – the gap between what people can imagine and what they can’t. In this case, that gap separated the end users from what we SharePoint folks know as Data View Web Parts. As we work together, we are bridging that gap.

She said that they need more detail in the view(s). When I asked “why?” she said “sometimes, we need to know things about the vendor, or we need to know what GL accounts had been affected by this payment.” That made sense, except for the “sometimes” part. I don’t like views that show things that are only needed sometimes. I prefer views that show what you need ‘all the time’ but can be made to show what you need ‘sometimes’ on demand.

I wired up a imagelittle example of one view with the addition of two Data View Web Parts. One web part contained more detail about the payment request and one contained more detail about all of the allocations. I connected those web parts – OK – I really want web part to be one word…webpart, why can’t we just call them webparts – Sorry, I just had to say that. I connected those web parts to columns in the view. SharePoint easily let me show those columns as links, and now when they want the additional detail, they can click on the link and populate the web parts. If they click on the payment request ID, they get its details and its allocations. If they click on the amount, they just get the allocations. Easy-peasy.

To keep all this stuff proximate, we also have to constrict the original view by limiting the number of rows it contains. Most people hate paging, so I gave her an array of options to consider. All Payments, All Payments This Month, All Payments this Quarter, and then of course, this year, last year, etc. I showed her how we can set the page limit and how we can dynamically filter the list to render things like All Payments for a specific vendor. Then, I gave her a homework assignment – go back and sketch out the perfect view. Next week, I’m going to help her build that perfect view. Maybe then I’ll have a better illustration.

Episode II

imageShortly after I posted the first episode in this little mini-series on leaving SharePoint, Christophe a.k.a. @PathToSharePoint suggested that Office 365 might be the answer to the problems we are having. I responded, telling him SharePoint 365, sorry SharePoint Online will have a role in our future, just not this role. It is as if SharePoint Online had shown up for an audition, missed the lead role but got picked up as an extra on a different film. Hey, that’s show-biz.

The reason we looked at SharePoint Online was because we thought it would be easy. In some ways, it would be easy. Unfortunately, the ways in which it would be easy are the ways it would be easy for us. We already know SharePoint, so working with SharePoint in the cloud would be a snap. We already have the content organized in SharePoint so moving it to the cloud would be a snap. We already own MetaVis, so moving our on-premises SharePoint stuff into the cloud would be…what’s the word for a snappier snap…let’s say easy-peasy. The problem is that we’re supposed to be making life easier for our customers. How does that work for me?

Once when I was discussing two options with my boss, he summarized my arguments by saying:

“Let’s see, the business benefits are the same. Option one is expensive but it would be easy for you. Option two is cheap but it will be harder for you to work with. I’m going to go with option two.”

That’s the thing with business problems, the solutions are spread across a spectrum of benefit. If we can’t have the whole rainbow, we have to focus on our members and our customers first.

The big reason SharePoint Online would be easy is because we are going to use it for a part of our normal business process. We have some stuff in SharePoint on premises that requires high availability. Specifically, it needs to be available when our office is without power. We don’t have any redundant power options, so we have to create redundant content. The content is in SharePoint, the redundant content will be in SharePoint online, done. That works really well, but again, it works for us. There are ways to make it easy for our domain users to log into SharePoint in the cloud, but our customers aren’t in our domain. In order to get them to login, they would have to have some sort of Microsoft account.

As far as Microsoft is concerned, this isn’t an issue because everybody either has or can have a Microsoft account. Yeah, but that’s not really the case. Some people don’t have an account. Some of those people don’t want one. Some people have a Microsoft account, but it isn’t associated with their job.

I had to create a Microsoft account in order to work with an association I belong to. As an old boss used to say: “the process was 1, 2, 6;” in other words, a snap. I don’t use this account very often, but whenever I do, my first task is to delete about 100 pieces of junk mail. This is the last thing I want our customers to have to do in order to work with us.

In addition, for security reasons, some of our customers are prevented from using personal credentials to access content while at work and others are prevented from creating such an account that is linked to their domain email address. In our on premises implementation, we had a separate domain and we issued credentials when necessary. Moving to the cloud seemed like a step backward as far as user experience goes.

Finally, in addition to all of the above, if we did go with SharePoint Online as a solution, our content would be in SharePoint, duh. I you remember the original post in this series, the problem with that is that most of our customers, I’d say 95% of them; simply want to download files from our repository. They don’t want calendars, tasks, blogs, wikis, custom lists, metadata and workflows – just the files. When that’s all they want, you either have to spend time to make SharePoint look less capable than it is, or you are going to make your customers wade through a process that seems overly complex.

If you are a lover of suspense, stop reading. I’m going to spoil the ending of this saga. We have decided to use Citrix ShareFile for this application. I’ll explain why we selected it and how we use/plan to use that service in the final installment of this series. Until then, I can say that we are very excited about it, our employees are very excited about it and the customers we’ve spoken to are very excited about it.