You are currently browsing the monthly archive for July 2007.

The goal of software is to get out of the user’s way. Software, and technology in general, is designed for helping the user do their job, and do that without noticing the technology in the progress. Users don’t want to worry about configuring, setting up, or dealing with the overhead of a tool.

“Oh, I can change the color of the text to magenta and make the font Scary Halloween? Terrific!”

“You’re saying I can arrange all of the fields on the page in any order I like? I feel like I’m back in grade school playing hide and seek again. Thank you!”

“I have seven options for how I can message my friends? Lucky me!”

Developers get pumped about new features. They love the idea of solving a new problem in a new way. However, I then usually end up saying something along the lines of, “I know you like the idea of making this piece of software so generic that the user can configure it anyway she likes, so it can do anything she wants, but then she’ll pay for the opportunity to poison your food and kill you as slowly as you’re killing her with your software.” Developers are trained to generalize their code and make smaller gears that do more, but, this generalizing of code tends to make them generalize the users, or the user’s tasks, too much.

Since programmers live inside the code, they put most of their thought into the code, and all the stuff that falls outside of that (user interface and interaction) gets a cursory glance. It’s great that you can produce a report in half the lines of code, and with that same code produce ten more reports, but that’s not so great if the user only needed that one report. If a function that took the user two clicks, now takes them five just so they have the option of doing more things, then you’re not giving the user a win.

It’s not just about simplicity. It’s about getting out of the user’s way. Removing visual objects decreases the choices a user has to make. Those objects might not even do anything like displaying static text, which seems nothing like the choices a button offers, “Should I click this button and perform its action or not?” Visual objects, even ones that don’t require interaction, still require the user to make a decision, “Should I pay attention to this?” The more the user has to ask that question, the less impact your visual cues have. Ever wonder why the users keep missing that one feature or option that they keep asking you about? Important things need to be obvious, which means making them big, bold, and attention whores. However, this task is made that much tougher in a crowd of ten versus a crowd of two.

The more objects there are the harder it is making any single one stand out, especially at the specific crucial moment when user needs it. But that doesn’t mean that the software needs to get in the user’s way by jumping up and down and throwing around blinking fonts. If each piece is fighting for the user’s attention, then the user will mentally tone them down. This process costs the user mental processing power. As a developer, though, you’re job it maximizing user mental power by focusing them on those tasks that only they can do, and not on the things your technology does well. You’re reward is the user forgetting to thank you because they’re caught up on something else other than talking about your software. Users talking about software usually means users bitching about their problems with your software. Make them do that to your competition, not to you.

Let me close with two real examples. The first is a simple one, a web page for a rowing club for signing up members, posting new updates, announcing new tournaments, showing pictures, etc. In doing a redesign, many technical advancements were made. However, navigation went from a sidebar of about 4 sections with 4 sub links each, to a side bar of about 8 sections with 8 sub links each. And, not only were there more links (without any substantial new content), but the sub links had a really “cool” hiding feature that hide the extra links as the user clicked to open another section.

Nothing against hiding extraneous options or content (hiding options is getting out of the user’s way right?), but when one set of links was opened the other hide themselves, and if the user wanted to jump between two sub links, then they’d have to keep opening up the previous section. Not a huge task you’d think, but users are worried about the page they’re looking at, they don’t want to spend time remembering where you hid a sub link. That reduces mental processing power by diverting it into the software, and requiring the user to manage the software’s links instead of managing the task at hand. I would’ve preferred seeing (I wasn’t managing this project) 3 sections with 3 sub links that flowed the user through their tasks instead of leaving steps open to users.

Users want to do stuff, they want to accomplish tasks, not contemplate options. This is exemplified in this last situation. We’re redesigning our flagship application (the other project was a smaller consulting job, which we do from time to time for certain groups). It’s a full blown (web based) application with complex business logic dealing with budgets and financial decisions and such, lots of moving parts. We offer a base vanilla package, but we customize it for the user based on their business practices. There’s only so much you can generalize.

It’s a friendly relationship, we connect with our clients on a personal level and help them do their jobs better, faster, and easier. We see the relationships we build as a selling point when negotiating with new clients along with our ability to customize the software to their specific needs. Most of them come to us specifically because they want to kill their own IT, and we do what we can to make them love us.

However, from a managerial and technical point of view, the more flexible and customizable the software, the less time we spend developing client specific features and fitting it perfectly to each clients. Development time costs more than sales time for us, so in theory, it sounds awesome if we could create an application that we just hand over to the user, and let them configure it 10 different ways for every need, and we move on finding more clients. Everyone’s happy, right?

Except we aren’t hired to give the user options and ways to configure our software. We’re hired to make their processes disappear in the ease of using our software package. There’s this continual fight I have to put up with both management and developers to keep the software from going in this direction of ubiquitous hell. “You can do anything you want,” sounds great, but when we know those two thing they want to do, we need to make sure we do those damn well, and forget everything else.

The engineers say they’re trying to re-engineer the processes, they’re adding more power to the application. Other management thinks we’re saving developer time, cutting costs, and giving us more time to focus on new revenue. In the end, if we were to make the generic putty mold of our dreams, then we’d alienate and frustrate our current clients, and scare away future clients. New features are an easy sell, but bad experiences are turpentine splashed on happily painted walls. Experience is a hard sell, and customers understand the value of good smooth interaction with software they’ve never used less than your salesmen understand the code behind the shit they’re selling. But, it’s the glue the keeps people around and magically attracts more people as well.


I love getting new hires. My friend at another company and myself just added new hires to our list. We’re both happy to have them, and it’s especially nice as they love doing the shit we hate doing. That’s the perfect situation when hiring a new person. Not only do they get work done, they also make you feel better about the work you’re getting done (or not having to do).

Not all new hiring goes so well. My friend’s new hire is his second attempt at filling the spot. The first didn’t go so well. The woman seemed great in the interviews, other colleagues liked her, and the President thought so too. This is the first time my friend has dealt with this kind of management decision, so it’s tough getting a sour apple on the first try. Still, others with decades of hiring experience couldn’t see any reason to choose another candidate over her.

The tough part coming out of this, though, is sticking with the “ideals of hiring.” Everyone says (you know “everyone”), “Hire personality – not necessarily talent,” but that’s tough thinking when you’ve had problems hiring such people. Who can worry about personality when they’re having trouble finding qualified candidate? Everyone says, “Hire slow, fire fast.” But people tend to hire for immediate needs and not for on going and predicted needs. And, what does slow or fast mean anyway?

Both of those are possibly the two most important ideals to keep in mind, which isn’t always that easy when thing aren’t going well. I’d also add, and this is one I don’t think most people would say when giving hiring advice, “Don’t just hire for yourself, hire for the benefit of the hiree.” What I mean is that it isn’t just a position that you’re trying to fill based on a set of skills. If they’re qualified and they accept an offer, then it’s not only their problem to like what you ask them to do. As other half of the equation, it’s just as important that you understand, at least at a basic level (not much more you can do until they’re on the job), what would make this new hire happy. This is the personality part of the ideals that most people don’t fully understand.

Finding the right personality is about finding someone who will enjoy the work they’re asked to do, and will gravitate toward the work they like and away from the work they don’t. They’re not just there for a paycheck, and it’s more than just doing work given to them. It’s about finding someone that will make everyone feel better by the work they do, maybe because they actually enjoy doing the work everyone else doesn’t like. Drive like that isn’t always easy to find, admittedly, but that’s why you hire slow and fire fast.

And of course, an easy way to start understanding this is to ask questions like, “What have you enjoyed doing in the past?” “Would this be interesting to you if you worked for us?” or “What of these possible tasks you could do for us would appeal to you most?” Granted, sometimes we have to do work we don’t exactly like, but it’s about supporting others and finding enjoyment through that support if some tasks are less enjoyable.

Finding a perfect fit isn’t always smooth sailing, people change, companies change, daily work requirements change, home life requirements change – impatience is abound. New hires might not know themselves, so they make it harder for you to understand them and know if they’ll like the work you’re offering. And hirer’s don’t always (usually in my experience) know what work they actually want or need to be done until they’ve got someone in front of a computer needing to do something (or what they’ll do after the first couple months).

Frankly, when hiring for the future, which is usually what you’re doing unless you’re hiring for a three month contract, then you need to hire creative adapters. You don’t know the future, they don’t know the future, but you both need to be able to work together as things change, and you both need to be creative in how to adapt to those changes. Hiring someone for immediate needs who doesn’t work out over time is more likely to gunk up the works and make you more impatient when looking for that right person. And remember, if you can, the absolute joy of finding someone that fits in better than expected, which means that more than just you are happy with the addition to the team.

“Make it user-centric” has been a mantra for technology for a decade or two, or at least that’s what new technologists are being taught in school. There are obvious benefits in making software that doesn’t beat up the user, forcing him to do what the software wants instead of what he wants. VRM, one of my more recent interests, defines a number of principles with the first being user-centricity. This is obviously good, but an unstated goal is community building, which makes me wonder, should community-centric not also be a principle? Is user-centric + leveraging network effects (principle #4) the same as community-centric? What does community-centric even mean?

Certainly web 2.0, if nothing else, shows the value in being community-centric. MySpace, Facebook, Flickr, Twitter, and all the other mega and not so mega web 2.0 software is being built around communities. Technologies like blogs and wikis are community-centric. And still, many of these aren’t user-centric, see Doc complaining about Facebook. So, I’m not confident that you can successfully create technology that ultimately builds relationships based solely on user-centricity without just being lucky.

Of course, VRM has multiple principles, but do those adequately turn it in into community-centric technology? If a defined principle is “relationships are more important than transactions,” then do you enter the world of community based technology? While we have technologists who make software that is user-centric with the knowledge that multiple types of users will use it, and while user-centricity is not inherently single user based, that doesn’t guarantee strong community results. If that truly is the key, building relationship and stronger connections, then it only seem wise in stating the obvious.

There might be some fear in making such a statement, though, if we don’t feel that we fully understand what community-centric means. There are plenty of web 2.0 failures where people tried making technology for communities and completely missed the mark. That certainly hurts the ego of technologists knowing there’s this great idea that we can’t really seem to perfect or understand. It still wiggles its way through our fingers even though we continually try to get it under control.

Being community-centric means building technology that facilitates stronger connections between two or more interacting parties. While user-centric means building technology that lets the user do what she wants without getting in her way. So, community-centric specifically means building better relationships – friendlier relationships, easier relationships, more personal relationships. These seem like primary goals of VRM, and why I like it so much. If you look beyond the consumer/producer interaction as solely a market interaction, buying and selling stuff, then as a commenter, Alan Mitchell, on the VRM mailing list notes, you help people “make plans, administer, organise, coordinate.”

These are qualities, or actions, that make Flickr more than a place to upload photos and YouTube more than a place to upload video. Did they build this into their system, or did they get lucky by making really good user-centric software that also happened to leverage the internet effect (network effect) of improving the technology as it brings more and more people together? I’m guessing they got lucky as many of the pioneering web 2.0 companies first broke the mold and showed us what success on the internet could mean. Is it time, though, to start defining these community building results as key features of technology built today? As technologists, should we start being community-centric as much as we try being user-centric? I think so.

Ending slavery didn’t end the problem of inequality. Lincoln’s emancipation proclamation, or better yet, and more eloquently put, Lincoln’s Gettysburg address (“Four score and seven years ago our fathers brought forth, upon this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.”) is to me equivalent of Project VRM and the concept of VRM, vendor relationship management. Yet, as ending slavery only led to segregation, VRM in its current state is only a half way mark – a transitional step – to a true, fully-integrated, and “harmonious” system.

When I first heard about VRM, from Doc Searls’ blog, I new there was something I liked about it. However, I didn’t get it as I think many people still don’t (and in all honesty, I still may not get it, but more so today than yesterday at least). As Doc described this concept more, I liked it more, and I understood it better.

VRM is about putting customers in control of their data, and giving them greater control over their interactions with vendors. Previously, vendors like Target, Verizon, or even your local doctor, have tried to utilize CRM, customer relationship management, systems to better “connect with” (aka sell to) customers based on the information they collected about their customers. Vendors have been in control, and at times this causes us, the consumer, a headache from all the junk mail and annoying advertising that’s – poorly – driven off this data (such a past purchases, demographic information, personal healthcare records, etc.). As companies figure out more ways to collect data, away goes our privacy and anonymity, and up goes our headaches from automated “relationship” building.

So, out comes this VRM concept. I fucking love it! And, I finally dig in and read the project’s wiki (and join the mailing list where I look forward to finding out what they’re saying, and hopefully contribute myself), so I feel like I actually understand what this is all about. Great – but I’m worried now.

Empower the customer. Take back ownership of your data and privacy. End the corporate slavery as Doc put it (“In a conversation with a honcho from a big retailer a few weeks ago, the guy talked about the Big Retailer Value System, and how important it was for retailers to “capture” and “own” their customers. “We talk about that all the time”, he said. I asked him to give me a word that meant “owning” other people. “Slavery”, he said. “Exactly”, I replied.”). However, as I read through the wiki and what VRM protocols would mean, I saw a gap – a remaining segregation.

Assuming VRM succeeds, there are still two separate worlds, two functioning systems, VRM and CRM. Both can live together, but that’s like having a water fountain for blacks and a water fountain for whites. VRM doesn’t in itself abolish with lousy CRM. Designed and constructed well, VRM shouldn’t encourage further headaches from CRM, and may alleviate some of the pains, but I don’t see the interest in, or misuse of, CRM systems going away.

The core problem with VRM is that it specifically addresses the problem from the customer side removing the vendor from the equation until the customer feels it’s appropriate (the customer is in control of his data). Because we’ve never really had this before, it’s a great step forward. Progress is undeniable, and it’s something I look forward to. However, a truly integrated system would facilitate the market place from both side, which VRM inherently doesn’t do. VRM establishes the previously non-existent customer side (it establishes a functioning, responsive – empowered – demand side for the demand and supply concept), yet the market place that occurs from these two sides meeting, the place where prices are actually decided, isn’t facilitated by either system. Market places must still be created.

[I think a lot of the confusion around VRM is that advocates talk about it in specific terms, in terms of market places and use cases. This makes sense because products and services are much easier to understand than hand wavy concepts. That can in itself cause confusion, though, when discussing the benefits of VRM using very different scenarios from healthcare to bank loans.

Additionally, the people interacting with VRM at this point also want the details. How will this actually work? At this point, you start stumbling over protocols, APML, microformats, and other architecture level things that confuse most people (including a techie like myself at times), so it’s hard connecting the dots from concept to reality at this stage.]

Selling the idea is can be tough. VRM has some interested parties, though, including the interest of some large corporations, which helps promote the idea and establish its viability. But that doesn’t in itself fix the market place problem. For that, you have to rely on those big corporations, and more likely, small entrepreneurs. It’s a nice thought that customers will start collecting their own data (is that actually part of the equation, I don’t know?), but that’s unlikely or at least a high water mark. How do you create or gather together a large enough body of customers so that companies are willing to actually spend time and money interacting? As so many Web 2.0 entrepreneurs have learned, “build a community site, get 1,000,000 users, make money” isn’t a great business model. The other alternative is for companies that currently hold your data to release it to you. Good luck with that.

Both situations pose challenges. One has to work if VRM is to work, though. And yet, that doesn’t solve everything. Even with a sizable community or communities, you’re still asking corporations to interact with this VRM system manually. That’s half the problem with the current CRM systems. It’s nearly impossible to establish real relationships with customers, especially when you have a significant number of customers who just walk in, shop, and leave, and that’s still an issue with VRM, if only in reverse. Sure, corporations can automate the process some and RSS and other technologies will allow other technologies to be built around them and bring the two worlds closer together, but that leaves me asking, “Do we really have to wait for that? Or can we skip this transitional step and move into a truly integrated system, must we have segregation before integration? And what do we really gain from semi-automated systems that simulate relationships?”

Maybe much of this is beyond the scope of VRM. Establish a means of storing and communicating and let people at it. Even though I’ve covered a number of large challenges and posed a few tough questions, I’m still a huge fan, and I think, given the chance, VRM will spread and produce new areas of economic gain. This will help rewrite how businesses and individuals interact, and that will in the long run help balance out control providing benefits to both sides.

[Update] Not even a second after I post this, I get my first email from the VRM mailing list. Apparently, I’m not the only one thinking this same thing as mailer Gigaboy20 writes nearly the same thing in a faction of the space: “The problem with Doc’s message of VRM is that it promotes one side as having more control over the process. Nothing in the universe can exist without a counter part to balance the experience…you’ll realize it’s not VRM or CRM it’s the + that forms V+CRM. Because it’s the + that is missing from the conversation that enables everything else to fall in place as a harmonious balance.” The + in this case, as I wrote, is the market place where the relationships are built, and where the actual price of business is decided.

Going outside the expected, trying different techniques, doing something different. This is what breaking rules is all about. Rebelling is fun and all, but there’s a purpose to it none the less. It’s about achieving different (hopefully better) results.

This is highlighted perfectly in a couple of Seth Godin’s latest posts about reorganizing retail space for better profit. It sounded like a decent idea as he’d written it on his blog. To him, it was a new untested idea, but it seemed obvious in the day and age of the internet.

His readers sent him email with their own thoughts and experiences. Apparently, most of them disagreed with him. Of course, those were the one’s who’d not done it. Guess who agreed with him? The one who didn’t spout off the assumed rules of business. The ones that got different results. Better results even.

Still, you can’t get better results if you aren’t willing to fail. If you keep following, if you keep copying the other guys, you’ll always be that person following the crowd. People don’t buy from followers, though. They camp outside stores days in advance to buy iPhones. Make your own rules. It won’t always work, but failure is essential to growth and progress.