TRAM:  A Development Framework That Focuses on the End User

To use the parlance of Twitter, I did a thing. 

To be more specific, I created a software development framework called TRAM. I put it together because Lift Enablement was growing fast. When we hired two developers (shout-out to Andrew and Megan) about a year ago, I needed to articulate my approach to technical/development projects. The result was an organizational tool that ensured we all used the same client-focused approach to projects.

I’m pretty psyched to say that it’s done a great job serving that purpose—but to my surprise, I also found it to be extremely useful as a communication tool. By that, I mean, the TRAM framework has not only helped the Lift development team communicate internally, it has also helped us communicate with clients—both technical and non-technical.  

Before I get into what TRAM is and how we use it at Lift, I have to admit that I’m a little nervous to share my framework in this blog. On the one hand, it seems so friggin’ obvious. On the other, many things that make sense seem obvious after you hear them. I’m hoping this falls into the later category. 

Basically, I’m saying my semi-fragile self-esteem hopes you find the TRAM framework as useful as I have. If you don’t:

And that’s valid. Everyone works differently. 

What does TRAM stand for?

Trigger: The action a user undertakes with the expectation of seeing something happen or wanting to make something happen. It’s a catalyst of some kind, such as clicking a button, hitting refresh, uploading a new record, etc. 

Result: Otherwise known as the tangible outcome that the user expects to happen after activating the trigger. By tangible, I mean a result the user can see, feel, or experience. Examples would be an updated dashboard or being able to view new records. 

Action: The technical process or mechanism that makes the result real or tangible. This produces the actual action. It has to occur in order to use the manipulated data that produces the tangible result.

Manipulation: The technical, backstage process that engineers all of the data and context provided by the trigger to facilitate the action, allowing the user to experience the result. 

You might be wondering why these aren’t in chronological order. That’s intentional. I put each step in the order of what the user cares about the most, to keep their needs front of mind when creating a solution. 

That’s all part of what we like to call the Lift Prime Directive: the business process drives the technology, not vice versa. 

Why I developed the TRAM Framework 

My goal—and hopefully, yours, too—is to deliver value for the end users by building for the people who will actually use the product or application. And let’s face it: that can be challenging for developers, who often want to either build the latest, coolest thing or something that will impress executives or the client’s tech team. 

But as we all know, if something’s really, really cool and no one uses it, it’s still a failure. Maybe just a cooler failure.

TRAM helps the dev team keep the employees who will actually use the end product top of mind.

How the Lift Dev Team uses TRAM

I’ve found it serves a number of purposes: an organizational framework, an educational tool, and a communication facilitator. 

For the organizational framework, we lay out a grid framework like the one below. First, we outline the triggers and the expected results—all of them, even when results have the same trigger. Then, we work through the action that enables that result and, lastly, the manipulations needed to digest the data and context provided by the trigger. 

We use it like a true organizational framework to help us determine how a build needs to work.

I also found it works as an educational tool to explain functionality to clients in a very straightforward, accessible way. It helps them understand how the stuff they interact with works and how there’s more behind the scenes that makes that happen. That also facilitates communication and helps us troubleshoot or work on improvements and iterations in a realistic way that keeps an eye on the business process. 

What I found using this framework is that it helps us pinpoint where friction is occurring and dig into it. 

For example, we had a client who wanted close to real-time updates to their ​​ERP system, but it was taking 25 minutes or so. We used TRAM to show how complicated the process was (on a high level: API calls, workflows, gateways, etc.). We saw where the friction was and dug in.

Because we used the TRAM framework, we could involve everyone relevant—technical and non-technical—to look at the solution from a business process perspective. We were able to include more people in that because it's not a purely technical conversation. We got insight from actual stakeholders—the people actually use the stuff we built. It was no longer a conversation occurring in a vacuum with only the technical team and with the executives.

Sometimes, as in my example, the best solution is a technical solution, but not always. For example, the users might need more training. Other times, the solution is a process improvement or another non-technical procedure that needs tweaking. 

The TRAM framework enables us to focus on the best solution, as opposed to the best technical solution. 

The Benefits of the TRAM Framework

The TRAM framework forces you to ask “What's the job to be done? What are we solving for?” As I mentioned, that shifts the focus away from tech to blue work, which makes sure you consider all angles of the situation. When the focus is simply on a technical solution, it often becomes solely about execution. 

When you're in a problem-solving process, you want to find the best idea. You don't want to operate from the place of judging the right idea—in other words, having preconceptions.

And when you want to change things, the TRAM framework makes you revisit why things were done and if those reasons still hold true. You never want to do something a certain way just because it’s always been done that way, but often, there are usually valid reasons it was built a certain way.

If those reasons have changed, it’s time to rethink things. If not, it’s probably time to optimize and see if there might be a new technology or something else that can be tweaked to make things faster and better.  

The TRAM framework has helped me immensely because it helps me prioritize the Lift prime directive—that technology should support the business process, not vice versa. I also think—but haven’t tested—that it could be applied to any transformative process, where someone does something and expects a result.

I’ve found TRAM to be extremely useful and I hope you do, too. And, you don’t—well, that’s just like your opinion, man.