By Shannon Smith, Director of Engineering Operations & Quality, K4Connect – No matter what part of the product development spectrum you work on, the focus should always be on the people you’re ultimately creating for. In the end, it is the user that benefits from (or unfortunately sometimes struggles with) the products and features engineers develop.  Why then, so often, are engineers so disconnected from our users while developing crucial new products? At K4Connect we’ve done our best to understand the so-called normal process in order to change it to fix the issues we so often see.

In a typical environment, end users are engaged by product managers and user experience designers early in the software development lifecycle.  At this stage features are merely thoughts, documents, and drawings yet to be brought to life.  As the product team determines the market need and possible usage patterns, these team members gather direct feedback from the folks that will ultimately use the feature.  These interactions with users are meant to drive quality designs, proper priority and appropriate scope to bring the most utility to end users.

Once a new product or feature is scoped, designed, developed, and tested, it is released into the wild for use.  At this point, customer success teams train users on how the features can bring them the most value.  It’s the job of this team to support the users that experience issues while using the thoughtfully designed, carefully crafted new product features.  Customer success then gathers feedback on how the product and features can be improved through this direct interaction with users.

In my experience, there is a deep chasm that has been created between end users and engineers that is filled with inefficiency and potential frustrations.  For some reason software development organizations hope that inserting a set of product requirements into the engineering department’s inbox will result in magic created through the use of semicolons and curly braces. Far too often this kind of interaction results in little to no interaction with the end user, and sometimes less than stellar results.

Throughout my time at K4Connect, I’ve worked with my team to actively address and close the chasm described above. While our product and customer success teams continue to work closely with our end users – older adults and senior living teams – I have worked hard to implement more R (research) into the R&D side of engineering through direct interaction with these users. Here are few lessons I’ve learned that will hopefully help any team looking to create products more efficiently.

1. Get out of the office

Have you ever gotten a set of requirements from your PM (product manager) that you know you can develop, but you really don’t understand the problem you are solving or why it is important? We all get the typical “as an X, I want to Y so that Z,” but do we really understand our users or the environment they have to work in?

Get to know your user
At K4Connect, we are developing products to serve older adults and those living with disabilities. We have a diverse engineering team with developers born in three different decades, but none of us fall into the older adult demographic…yet. This makes it challenging for us to fully understand all use cases.

I encourage developers to spend time with our members (end-users). K4Community is being used all over the US, from Masonic Villages in PA to Eskaton in CA to dozens more communities. Thankfully, we have several HHHunt and Kisco partner communities just a few miles from our headquarters in Raleigh, NC.  This provides us a chance to have engineers go on-site and see the impact their work is having and see the way their features are used.

Through this direct interaction K4Connect’s developers get to see how someone who has never used a tablet uses their feature. They get to see how someone with reduced vision or dexterity use their feature. They have the opportunity to see their feature through the user’s eyes.

Use your product where it is used
Beyond meeting the people who are served by our systems, going on-site allows us to experience our software with the full spectrum of challenges presented by technology.  Senior living communities are not always on the cutting edge of Internet service, networking, or computer upgrades. There is a substantial difference in the computer hardware and Internet speeds in your average development shop and those found in your average senior living community.

Of course, we try to test how our apps respond to latency, poor connectivity, et cetera.  There are also some great simulation tools will give you some insights and uncover some issues related to sight or other cognitive issues. These do not prepare you for someone trying to pull up your app on an 8-year old desktop in a browser you wish didn’t exist using WiFi slower than your 3G hotspot could provide.

At a previous job, I would offer to pay for a coffee if a developer or tester would take a laptop to the coffee shop where the connectivity was poor, just so they could feel what the user would feel.

Getting out of your office will show you things you may never see from your desk.  It may seem like it is taking away from your development time.  You have to look at it as an investment in developing your empathy for your users.

2. Connect with power users

You will not always be fortunate enough to have users nearby, where you can stop by for a visit. That should not stop you from connecting with the people your products serve.

With K4Community, we are lucky to have several power users. These members love what our product brings to their community and want to be a part of making it great for everyone. In my time at K4Connect, I have been able to visit with users on-site, but I have also been able to leverage our power users to test out new features like our video calling feature. These members are happy to help out and give candid feedback about the quality of a feature. And, as a bonus, we get to involve them in the development process!

Our power users also work with other residents in their community to get them started with K4Community, some even hold classes to train others on using their provided tablet as some residents have never used one. These interactions make the power users great sources of information, even within a development cycle.

3. Align your mission with the users’

The number one way I have found to decrease the disconnect between developers and our end users is the alignment we have between our mission and the mission of the residents, family members, and community employees. We all want to improve the lives of our members, the residents. We all want their lives to be simpler, healthier, and happier.

K4Connect is unabashedly a mission-centered company. We exist to serve older adults and those living with disabilities, and those that care for them.  Every developer at the company knows the mission and has their own individual way to connect with this mission. When they are developing, I ask that they continually ask themselves, “does this help us accomplish our mission”? If they can’t easily answer the question, I expect them to ask. The team is given the tools they need to solve problems, whether by talking with a resident, visiting with community employees, or working with family members.

For us, and I imagine for you too, it is important for our developers to holistically understand the problems they are working to solve. We believe without empathy for our users, they will be unable to solve the problem in the most effective way. Everyone on the K4Connect engineering team is doing all they can to develop empathy into our solutions.

At K4Connect, every team member is expected to advocate for the end-user. In the end, it is the user that benefits from or struggles with the products and features we develop.