If there’s anything I keep in mind about the user experience (UX) is that it’s not just about design. Instead, it’s about business. UX is just a sliver in the overall process pie. For example, we get caught up in project milestones. Did you ever see a set of milestones like this?

1. Start UX
2. Finish UX
3. Get first user
4. Get first 100 users

While you may think it’s a bit simplified, I use this strategy all the time. Why? Because it puts the business vision at the forefront, not the design process.

As a developer and manager, I think deeply about this. Modern CTOs know all about programming or they surround themselves with those that do. Still, as CTO I must have a business minded approach. 

 

Where Does the Button Go?

I’ve lost count how many times I’ve witnessed an argument that goes something like this:

“I think the button should go on the left.”

“I think it should go on the right.”

“But the left is better. I read about it.”

“I disagree. The right is makes much more sense.”

Then they just repeat the above four lines over and over again. How do I respond to this? I tell them we’ll split test it. I validate that both views have value, and testing will help us decide. And guess what? Ninety-nine-point-nine percent of the time I never do the split testing, and the issue never comes up again.

Why does this happen? People want to be heard. It’s not even always about power or ego. We, as human beings, need to be heard. Deep down, they really don’t care about the button at all. Like birds, we just need to sing sometimes.   

The Hallway Test

This method works like this. I test my software on the first random person I encounter that has no vested interest in the project. You want an answer like, “Yeah, whatever. That one’s the best.” The reason this works is that their response is free of bias and purely practical.

Getting Feedback

I don’t do group user testing. If I ask you to critique something, you’ll look for negatives. On the other hand, if I ask you what you love about it, you’ll look for positives – but some negatives will slip in anyways. That’s why I always ask what they like about something, but I’m very much looking for what they say they don’t like. It’s kind of like the Hallway Test – it’s unfiltered feedback. I don’t even bother to ask what they “think” about an app. When I ask them to think they get tangled up in a mind game trying to be fair, balanced, or maybe even inoffensive.

Monkey See, Monkey Do

I have a client in the highly specialized field of law. How do I test their app’s usability? I give it to a person with no legal background at all and see if they can figure it out. I’ll tell my brother-in-law who owns a motorcycle shop, “Hey, check this out. Create a deposition for me.” Then I’ll watch him scan the screen.

“Oh, here it is,” he’ll say and click on the “Add Deposition” button. Then I’ll watch him use the application, and I’ll pick up on intrinsic value through my observation. You see, when people use apps, there’s a good chance they’re multitasking – at least mentally. So I don’t want it to be sophisticated, I want it to be simple, easy, and useful.  

In the field of medical devices and other industries, human factors engineering frequently comes into play. It’s basically the concept of making the human-machine interface as friendly as possible. The designers consider things like, what if the surgeon is tired when using the device? Or what happens in a bumpy ambulance ride? Or if the lights go out? How about extremes in temperature or vibration?

The point I try to remember is this: everyone’s distracted these days. I design my applications, therefore, to deliver the lowest common denominator to fit snugly in the user’s world.

Product Design

This isn’t a committee process. The truth? I do wireframe designs by myself, because if you try to design a horse by committee, you get a camel. I do the wireframing and involve one or two other people (designer and developer). I like to collaborate with developers early so they feel like a part of the process from the get go. They also offer me real time knowledge which can circumvent time killing development snags.

Architects that build buildings have huge amounts of stress and variables swirling around them. They almost always work in very small teams. This enables them to deal with new iterations in the most agile manner possible. They’ve been doing it that way for centuries because it works. That’s the kind focus I emulate.

Core Goals

If you forget everything else in this post, remember this: Always Return To Your Core Goals. This is a list of 3-5 things that your project or product is tying to accomplish. These are the guiding beacons that rescue me from the chaos and rabbit holes that drown projects and stifle business.

I go off on tangents all the time. I lose my course. That’s a normal, and necessary, part of the creative process. But I need something to go back to every time to set my ship straight again. Have your core goals prominently displayed.

Super Creepy

What’s creep? It’s the trap of trying to be everything to everyone. In the business world, this means branching out into niches where I can’t be successful. In software development, it means losing sight of core goals trying to be too cute, clever, or complete. I end up adding features that I don’t need.

When you go to buy a hammer, you buy a hammer. What if you found one with a first aid kit and flashlight built in? Useless, right? In software, it’s not as obvious, since concepts are harder to get your head around, but it still applies.

It’s the Law of Diminishing Returns, which in my book means if you love chocolate ice cream, you’ll love it a lot less if you eat it three times a day. Enthusiasm wanes, so we look for something new, even if it’s not useful. We end up developing it to death. I’ve witnessed people become addicted to building technology. They are builders and developers, not CTOs.

The way I avoid this trap is to shift my reward focus. This means I look at milestones that go beyond development. I get my serotonin fix from business milestones instead.

Edge Case

An edge case is something that can happen, but isn’t obvious. Now, I get to choose if I solve the edge case or not. And almost every time, I’ll make a decision deferral. If it can be put off, I’ll put it off. I’ve very good at not doing things unless I have to. This doesn’t mean I’m negligent, but I prioritize with a razor. I can’t afford to burn unnecessary fuel, be it money or time. If I can’t make the call independently, I get together immediately with the person who can.

Remember, perfection is the enemy of good. My app might be vulnerable to unwanted outcomes. How many times will this occur though? Is it an acceptable rate of failure? If my baby is ready to go, and it’s the bottom of the ninth inning, I can deal with the edge cases later. And, yes, I’ll keep a detailed list and come back to them.

Test The Waters

The point? Look beyond UX. Maybe you have great tech skills and people management capabilities. This is still not enough to be a truly modern CTO. Instead, I need to test the depths of the pool. What don’t I know? How about corporate budget forecasts? Do I know what’s important to the CFO? It certainly isn’t where the button goes.

Again, when I don’t have the knowledge, I hire people that do. I learn from them and ask questions. I pick up the phone, send an email, or leave a message for a C-level person at HP and ask a question. No answer? I try again, and again. I might ask if they have a book to recommend on the topic. The modern CTOs drive for knowledge must reach far beyond the confines of technology.

What should you do?

Are you or your team lost in the product? Significant resources invested with not a whole lot to show? I’ve seen this happen many times, it’s why I’ve written about it in my Book and here on my site. I have experience that you can leverage. Tell me about your situation so I can help. To set an appointment with me simply click this link to reach out. Something else on your mind? Whatever you need, I’m here. Life is meant to be done together, just reach out.

---

This post comes from my upcoming book, Modern CTO. Pre-register for a copy here.