At least once a month, step out of your cubicle or office and spend a day on the floor. It will make you a better software designer and developer, it will help you make better software for the folks on the floor, and it will build a better relationship with them so issues and ideas can flow.

I spent Friday on the floor of my work. As I do at least once a month. My software and their workflows are significantly better for it.

What is the floor? It’s the place where folks will be using your software. If you are writing a warehousing system, it’s the warehouse floor. An accounting system, the desks of the bookkeepers. A trading system, the trading floor. A social network, the coffee shop.

One of the biggest problems with software design and development is knowing exactly what needs to be done. We developers have tried a lot of things, and continue to find new and better ways to figure this out. From requirement specifications, to use case stories, to meetings, to prototyping, all different ways to figure out what needs to be done. We work with analysts and managers to understand the problem domain and make design decisions. We work with some of our users to discuss and test ideas.

But no matter how many meetings and documents and email conversations we have, we developers often miss what the users actually need, want and mean. Communication breaks down like the “broken telephone” game. Our interpretation of the systems and tools may help them somewhat, but just as often, they miss. And our users need to work around the tools we give them to keep going.

But if we, the designers and developers, were on the floor, we could see with our own eyes what our users actually do, and how badly or brilliantly they do it. We can see the problems they face that they cannot communicate, the things they spend more time on than they should. We can see the things they have not mentioned. We can see how our tools really help or hinder them. And we can talk with them directly about it, in context.

There is no way we can get real work done on the floor, we need time and solitude to design and develop. We need to take away from the time spend on the floor new ideas, better solutions or at worst, a clearer understanding of the problem space. And apply our talents to that.

It’s not easy to explain to a manager that you need to take a day off from programming and spend time with your users, sitting next to them as they work or riding along. For some managers, that’s violating the chain of command or “working behind their backs”. For others, they feel they are paying you to program, not to understand, that be their job. The only solution I ever found that worked was to start the conversation early, spend short amounts of time on the floor with users discussing specific topics while they observe and let them see for themselves how much better it works when you and your user put your heads together.

But I think the biggest gain I get from spending time on the floor is the relationships that get built. I get to know my users and how they think, and they get to know me. And once we know each-other, it becomes easier to communicate. I get to learn and speak their language, and they get comfortable enough to start sharing their ideas and issues. And the day you come back on the floor with a feature or change they asked for, that is a very good day for all.

As a designer and developer, I am at my peak when I understand the problem domain, and am pretty useless when not. You can learn only so much from meetings and emails, but without knowing what questions to ask, you will always miss out on the “unknown unknowns”, the things you do not know that you do not know. On the floor you will see things and hear things that you had no idea were happening, can meet the folks doing those things and discuss and understand them. That increases domain knowledge, and that makes you a better designer and developer.

So, once a month at least, spend some time on the floor. Feel the pulse, get involved in the conversations, look out for new behaviors, activities and issues and talk about them, observe and identify the flows and habits, and build a better relationship with your users.

Soon, you will no longer be that mysterious IT person, you’ll be part of the team. Their part is to do what they do, your part is to make great systems for them. Together, every one wins.

I spent Friday on my floor. I learned that my users had no idea certain features they wanted did actually exist, and showed them how to access them. I found out about several design decisions that missed what they needed (and even corrected a few). I found out about a process I had no idea we had. I improved my domain knowledge immeasurably, and look forward to spending more time with them on the floor.

This article is part of a series on Hiltmonisms, a series of catch-phrase ideas that I have been learning, developing and using for years to improve my craft and the craft of those around me.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.