For the last three years or so, I’ve been working on my employer’s flagship product, Logos Bible Software. It’s the 4.0 release of a mature product with a large, established customer base. The 3.0 version of the product has been out there for several years, and it works just fine, but it was built on an underlying technology¹ that was better suited to 1999 than 2009. It’s starting to show its age.

(For those of you who don’t know, Logos Bible Software is a desktop application for reading, searching, annotating, analyzing, and generally playing around with Bibles and biblical reference works — dictionaries, lexicons, commentaries, maps, and so on. Think of it as Photoshop for pastors and seminarians: Required equipment for professionals, but very nice to have if you’re a hobbyist.)

So, we embarked on a ground-up rewrite of the software. Not only that, we attempted a ground-up redesign of the user interface. Sure, we re-used some of the code that shows a book on screen, some of the searching guts, some of the this and that and what-have-you. But the user interface, the part anyone ever sees, is as far as I know, completely new stuff.

I was the software designer for the project. I suppose all the cool kids are calling themselves “Interaction Designers” or “User Experience Experts” or some such. Well, if it looks good on your business cards, sure. But I prefer to be called a Software Designer, because that’s the simplest way to say what I actually do, which is to make pages like this:

I like to think of it this way:

• If a software program is like a construction site, then I’m like the architect. I drew the plans. I didn’t build anything, and the core ideas weren’t mine. Still, I made a thousand tiny decisions every day, pondering such imponderables as: Link or button or link button? What happens when you click it? Where best to put it?

• The president of the company was like the owner/client. It’s really his baby, and he’s the one that wanted the thing built in the first place. He has ideas, let me tell you. Lots of ideas. My job as designer is to translate his ideas into workable designs. Sometimes that means telling him he’s brilliant. Other times, it means telling him he’s crazy. Sometimes it means doing what he wants anyway even though I think it’s crazy.

• The lead developers are like engineers. If an architect says, “We’re going to build a 10,000 square foot room with no support columns” the engineer is there to tell him that it can’t be done. Or that it can, but not with the budget we’ve been allocated. When it comes right down to it, the designs are just suggestions of what could be; once you get out to the job site and start sinking knee deep in the mud, your pretty blueprints may not count for much.

• The other devs are like the tradesmen and craftsmen who actually do the work. Like carpenters, plumbers, electricians, and painters, they are all highly skilled at making wonderful things. The Logos team is the best. Okay, I’m sure Google and Microsoft have great teams. But really, the Logos dev team is a highly motivated, highly intelligent, highly worthy group of men and women.

In going about my part of the job, I used three design principles that I shamelessly stole from the Shakers:

(1) Is it necessary? Not every great idea must come to fruition. This is all about prioritizing the design goals, and not getting carried away with the client’s exuberance. We were relentlessly minimal about the design of Logos 4; it’s fully featured, but it has just what it needs and no more. At every turn, we asked ourselves: What’s the simplest thing that could possibly work?

(2) Does it suit its purpose? This is really the hard one, because you have to know what goals a given feature or application is trying to accomplish, and then you have to figure out how to measure whether or not they were, in fact, accomplished. You can fail at either end: Identifying the right goals won’t help much if you build something that doesn’t accomplish them. Testing a product to death won’t help much if you’ve identified the wrong goals. “Yes, it does the wrong thing entirely, but it does it really well!”

(3) Can it be beautiful? I don’t actually do the final art on projects I work on, but I usually go the extra mile to make my wireframes and mockups look as close to final art as I can. Why? Because I find it’s not that much harder for me to do,² and it gives everyone, from client to dev to art designer a better vision for what we’re trying to accomplish. I don’t make pixel-perfect artwork, like some do, but pretty close. In any event, I try to do my part on the aesthetics of the thing, because as we all know, pretty things work better.

If you can actually achieve those three goals, you hit that sweet spot in design called “elegance.” With Logos 4, I think we did. And good. (I may be biased, of course.)

Oh, and we made an iPhone version of the desktop software while we were at it.

—

¹ DHTML and JavaScript, shudder.

² I use Adobe InDesign to draw program screens; yes, it’s overkill, but I know how to bend it to my will.

Nov 7, 2009 | Eli Evans | permalink | comment