As someone who joined the workforce before the terms ping, Slack, "at" and using Google as a verb I know that I come with my inherent biases, but the fact is that reading and communication through written form is often hard enough. Technologists will be the first to tell you that technology can and will not solve all of our problems. There are in many cases that I can think of where others have bloated software to a point where it became inhuman or unusable.

Sometimes we try to build things that are meant to be usable for everyone, but we forget that the more features that we add the more we will have to teach people how to physically use it, but teach them how to apply their work to this new technical strategy.

I sometimes talk about how simple TransitChat was meant to be and it can ruffle some feathers when I talk about how the Transit community need something simple to use. Transit is complex, there are locations, routes, and stops that change through out the course of time. Any product that you apply to transit will take on this complexity, there for the complexity of the product needs to be below the threshold for the lowest common denominator for every feature that you put out there.

And to be frank I think this is why Email has had such a successful stranglehold on the way things get done in the Transit industry. Email is just one of those things aside from etiquette that you generally don't have to train people on. And that's why we use that to our advantage at TransitChat. We are simply trying to build on top of it to make email better.

I love email

For me email is almost perfect.

I have a list of items that come in, I know who they are from where they are from and when it was sent with files already attached with the context. I commonly have 0 unread emails in my inbox at all times and I have a couple of strategies to get that done from using folders, to using it as a to do list for my day, to just putting files in my cloud storage using the PARA system (Projects, Areas, Research and Archives).

The fact of the matter is the reason why email doesn't work is because it doesn't scale. Your efforts to keep your inbox clean has no effect on your team aside form you being the only one who can find and forward the information you need at any point. Which can often feel like you are the only friend with a truck on move-in day wasting your time keeping other up to date after you have taken the time to fill your cup.

In no particular order I have a list of things that I try to keep in mind when I am designing workflows in TransitChat that I have come to love with email that build on the simplicity and "trainingless" nature of the platform.

No nested threads

All too often we work with software that has to do's with to do's and the ability to leave comments everywhere.

Why would you do this to your users? Because they asked for it? Because you can? Because you intentionally want to send out another email to alert the user about a comment on a to do that is buried 3 layers deep in your teams to do list?

Email is so straight forward. There is a timeline. We as humans perceive time linearly and that is why email makes so much sense. However, the constant forwarding and replying and creating of new threads or conversations that are tangentially related to this topic can and will create confusion among the ranks. Which is something that I am so critical of when it comes to email.

But this for me raises the question just because you can do something will this make the product harder to use, navigate and onboard new users to? While it may often seems as simple as just allowing there to be a new nested to do a click away, you want your audience to be able to answer "Where am I?", "How did I get here?", and "What is this in relation to?".

Being the "old head" that I am I remember hearing about the limitations that the Palm Pilot team put on themselves to be able to get anywhere with three clicks. How many pieces of software do you work with that can claim THREE clicks for an entire system? Someone's job was just to make sure that you could use that little plastic pen and navigate the whole system with just three clicks on a screen with no color or contrast that was slightly more functional than a Gameboy pocket.

"Trainingless" products mean taking away etiquette choices

When it comes to software design you can have features that might not be fully documented on how you "should" use something or special configurations that allow you to use something in a different way buried in the settings for one customer in particular. But that choice that you are choosing to make in a piece of software shared across a team, department, project or organization can make ripples and often someone exclaim the dreaded "That's not how we do things around here".

These preferences leaning toward a way of doing something define out the etiquette withing your organization and team and create products that either are difficult to train for or products that cannot be taught because internal stategies need to be designed to "make it work for us".

Nested lists are great example of this.

Do you allow your team to have nested lists? Does the platform have a checkbox to allow for nested lists? If you can have a nested list how many levels deep can it go? Can you have a comment on a nested list? What about a nested list item?

This freedom in software often leads to confusion, processes that are hard to control and teams that can get lost within their own platform killing the adoption of what could be a great solution if only there were some "limitations" rather than relying on etiquette or the unwritten rules of "How we do things around here".