Look, I am not a professional HCI or interface-design person, let’s just take that as read. If you want to watch the real experts go at it, I recommend Boxes and Arrows. I’m as much a design guru as I am a programmer, and I’m not a programmer. (Though our godly sysadmin has agreed to take on a small pair-programming project with me; if this keeps up I may actually start to suck less at programming.)
That said, let’s talk a little bit about what persona development like yesterday’s is intended to accomplish, and how that relates to where we are vis-a-vis design in repositoryland.
It’s really hard to put yourself in the mindset of “the user” when you’re trying to put a piece of software together. Working from standards or other specifications, that’s easy; the worst you’ll run into is linguistic ambiguity. But “the user”? Who the heck is “the user”? And that’s the point. There’s no such animal as “the user.” There’s various sorts of people who will be using your software. Persona development is an attempt to ditch “the user” in favor of a portrait that actually resonates, a concrete mental image that one can build a product or service design around.
Many design processes attempt to circumvent the “the user” problem with focus groups and survey research. This produces useful information—but with serious caveats. One, you can’t design for a statistic any more than you can design for “the user.” Two, you cannot rely on people to reliably introspect about (or even tell the truth about) their current or future desires. You just can’t. If you could, we’d all be designers! What you can, if you’re careful, get a sense of is what their current behaviors are and what their needs (expressed or un-, and they’re mostly un-) might be, and that information can and should fuel persona development.
We know a fair bit about researcher behavior vis-a-vis their research products; we really do. We also understand the landscape researchers operate in. This is all good, and I used my personal understanding of this realm to create Dr. Troia. But understanding is not quite enough; there’s one more small trick to persona development that I think illustrates where the repositoryland train jumps the tracks. Videlicet and to wit: a good persona is, insofar achievable, the typical case, as unextraordinary for the represented population as possible. The thinking is that if you design really well for a few mostly-typical cases (and yes, you’re allowed to throw more than one persona at a design problem, though you want to stop at five or so), what you come up with will more often than not handle your edge people too!
We have not been designing repositories for a typical, representative faculty member. We have been looking at physicists and computer scientists because they are self-archiving in huge numbers, and we have tried to imitate what worked for them. The catch, of course, is that most faculty aren’t physicists and computer scientists. They aren’t even like them; if they were, we wouldn’t have this self-archiving problem, would we? Physicists and computer scientists are an edge case. If we design for them, we lose everybody else.
So Dr. Troia isn’t a physicist or a computer scientist. Mutatis mutandis, she isn’t a flaky technophobe from comparative literature, either. (Everybody knows that potshot was at me myself, right? I have a BA in comp lit.) As best I could, I tried to make her what I normally run into, what I generally expect to see when I meet a new faculty member.
What does Dr. Troia need? Well, first, let’s look at what she doesn’t need. She doesn’t need increased citations. Sure, they’d be nice, but she doesn’t need them. She needs to get her work in the right journals with as little pain as possible. Similarly, she doesn’t need someplace to put her preprints and postprints; these are of so little value to her that she essentially throws them away. If we as repository designers and managers want those preprints and postprints, we’re going to have to get them as a byproduct of a system that does something Dr. Troia does need.
Worse yet, she doesn’t need to manage her copyrights; see above about the right journals. If we want her to (and we want to know when she’s done it), we’d better change her motivations or make copyright management an inescapable part of our systems. She doesn’t need a self-archiving mandate, either. We might like her to have one, but that’s not the same thing. She would comply with one if it existed (because she complies with everything she’s required to comply with; like most faculty, she is a pretty compliant creature where money and career prospects are concerned), but she would never suggest one, never fight for one, never even vote for one, because she does not need it and it represents additional work for her.
(I am reminded of the standard template for software-development projects: “1 Build code. 2 ???? 3 Profit!” Except here it’s more like “1 Say the word ‘mandate.’ 2 ???? 3 100% self-archiving rates!” The reason I fell in love with Minho’s solution is that they sensibly put “Bribe faculty” in slot 2.)
What Dr. Troia does need, and would immediately admit that she needs, is secure, networked, backed-up, maybe even version-controlled storage with access controls. Not (I cannot say this strongly enough) archival storage, because she needs to use it for in-progress work. But storage that had archival bolted onto the side with nice pointers about what to archive and when and how, that she might well use. Goes double if the system makes it easier for her to send her work to journals, or comply with data-retention or funder open-access requirements.
Do our repositories make any of that easier? Do they hell. They make it harder, and they don’t sweeten the pot by solving Dr. Troia’s other problems. No wonder all the Dr. Troias out there don’t use them.
I hope to write up a few more repository-related personas in the next week or so, and then (hello, Les) I can start talking turkey about repository system and service design.
