Linear method madness, sans user stories
In the pursuit of efficiency, Linear overlooks the “why” in UX research, resulting in the development of features with unclear purposes and functionality.
Linear, is a shakeup of the tired project management software field, pragmatic and effective and focuses on providing UI/UX that is fast and not bloated.
Linear is opinionated about how to manage projects. I’m all for opinionated software; it’s products like that move the progress forward. Designing opinionated software is kind of a high stakes game. Show people the way to be more productive, doing things differently with your product, and it’s a huge win. But when software gets in the way rather than helping, it’s the worst kind of opinionated software.
Beyond the initial excitement, having been using Linear for a year and a half, Linear appears to signal a somewhat different approach to work, but fails to deliver on methodology.
Take Linear’s concept of Project, for example. It is actually what you would call a Feature. If you use those projects as features, Linear does not offer anything to organise your features under, except Teams and Workspaces. Do they really expect you to designate your product as Workspace just because Linear does things differently?
We tried to use Linear’s Projects as features, as traditional Projects and as Epics, neither way made sense. Just recently Linear introduced “Initiatives” which is basically Epics or Milestones. It’s a mystery why these and other PM concepts shuffled their names.
Support and documentation did not explain questions, and gave the sense that this product is open to interpretation, and different teams may have very different uses for the same concepts.
There’s an ideology that Linear uses in designing and developing, it’s evident through different design decisions, sometimes in quite mad ways. Linear’s way of thinking made it eccentric and not in a good way.
Linear Method Madness
Linear has its own methodology, Linear Method, which seems to have emerged from “dogfooding” their own product. It is an agile methodology, with added pragmatism.
Once you delve into Linear Method, it becomes clear why Linear became like this. Front and center there’s this particular declaration:
Yes, create tasks instead of wasting time on user stories. User stories do not clearly communicate the tasks that need to be done. You would have to read them, figure out the tasks, create those tasks, and who has time for that!
And since all has been done before, and everything is a copy of a copy of a copy, and we already know how any functionality works. Therefore, it would be a waste of time to derive that spec from a user story, as you would arrive at the same conclusions and end up creating the same specs and tasks, as you would without user stories.
What if a customer requests a feature? Linear says that customers also know and have used all kinds of software, and if they want something, they will describe to you what they want. Where they want a particular button or field, and how it will perform a function they need. And you will know what they mean because everything was done before. You would not need to discuss user stories with them.
If you think this already looks like some accident waiting to happen, it is so. All the red flags: co-designing with the client, lack of involvement from UX at a critical stage to understand what you have to build, having managers and developers, and your dog working on functional tasks with only superficial UI-level design input.
In return, you get faster results. Hopefully, a working product, provided that you copy the UI/UX of some known functionality that exactly matches the problem you’re solving.
When you look at your customer’s needs through a very narrow window and design your product through that window, every feature would become confusing, not making sense in the overall product context.
Linear has another argument for efficiency: don’t involve everyone in everything! Let them work and do what they’re doing. Not only will you waste designers’ or researchers’ time on user stories, but by involving other people like developers you’ll waste their time. And there’s no need for that when everything that you build is a copy of a copy of a copy, been done before.
Design does not happen by itself. Neither is it a result of solely the designer’s work. Everyone is involved in some way or another. And the more people are involved with design, whether it’s just giving feedback or test driving it, the better the product is.
Contributing to design is not just drawing UIs and writing specifications. It’s learning and understanding the design principles, giving input and discussing. Some may say that a developer doesn’t have to know UX design at all, and that’s okay. But when a developer is aware of the basic principles of UX design, it will reduce the number of revisions, issues and significantly improve the quality of the product.
The bridge that helps to understand how design relates to functional requirements is the user stories.
Building your product by-the-numbers, as Linear suggests, skips the crucial step of understanding the user and innovating beyond competitors. Skipping design stifles innovation, resulting in a generic, uninspired product that can’t compete.
Linear itself as an example
In Linear you can pin a tab on some task or project, but then, in that tab, navigate to a completely different, unrelated place. I couldn’t understand; I thought maybe I am using it wrong? I asked Linear support, and they replied that everything is as it is supposed to be. You can pin a tab! What else do you want?
Then this pinned tab is no different from a regular tab, except that it stays on the left side without a title. Within such a “pinned” tab, you can navigate to another issue, view, plan, and it will stay as that tab’s starting point. If you restart Linear, the pinned tab will not return to the context you pinned it on.
There’s UI-level pinning of a tab, but no pinning in a sense that this is supposed to be a feature that helps the user organise.
What you would expect to see is similar to how web browsers do it: once you navigate outside the context of a pinned tab, it opens a new tab for you, keeping your pinned tab within its context as you wanted.
Here we are in Project 1, and we pin a tab with this project:
In this tab we can, for example, click on “Projects”,
Next, in list of projects we select some other project:
And here we are in the same pinned tab which is now dedicated to a different project! Even the breadcrumb navigation would not help in getting back to the original project:
Linear support was no help with this, responding that pinned tabs work as they should: you can pin it, what else do you expect?
Having tried to convince Linear’s support that pinned tabs aren’t, I had an exchange with Linear CEO & Designer Kaari Saarinen:
He didn’t seem to grasp what is wrong either. But couple of months later, Linear got an update with changes related to tabs. Are there pinned tabs finally? No, but they “fixed” them! By adding breadcrumb navigation within tabs, suppose to help you return to your original context of the tab. Yet pinned tabs still don’t stay pinned.
Going through all the trouble fixing symptoms and not the cause. Yet in the process of adding navigation within the tab, nobody asked — why are we doing this? Nobody noticed that such a UI pattern looks bizarre and overly complicated.
This is a result of following the “Linear Method” and excluding user stories. And since it’s it’s done according to the task that says “make it possible to pin tabs”, then it’s technically correct!
A user story would have provide background to understand that this is a productivity feature to allow the user to store and quickly find pinned item.
With user story, they would have enough context to deliberate what kind of contexts and views in the app would be “domains”, when do you navigate within the same tab and when do you open a new one.
They developed this feature, and then returned to review and “improve” it and still nobody on their team knew what pinned tabs are really for.
Such extreme pragmatism is born out of startup culture that requires company to show high product growth rate. When chasing investor money startup is measured on dynamism and feature turnaround time, from inception to release.
If you can save up to 50% of time by not thinking about anything, and rapidly deliver features that technically kind of do what they should, such team would look like high performing miracle to investors.
You don’t even have to use User Stories and Story Maps. Those are even considered somewhat outdated. There’s a more modern and pragmatic way with Jobs To Be Done methodology.
