Principles For Designing Better Products
I tended to believe that with all technological advancement, we will work less, smarter and better. But with years it seems that we add more mass to our process and decision making which in the end is reflected on our products or services.
We have more and longer meetings. Bigger teams. More complicated processes. More time and resources spent. On a yearly basis, we get more management tools and hacks. We preach simplicity but forget how to build a useful and usable product. We want innovation, but we keep rigid roadmaps that can’t be changed. People want to contribute with great ideas but all they end up doing is pick up another ticket from Jira. And with all of that, we get more and more waste. But there is a better way of designing and building, one which has less mass.
Recently I had the pleasure to finish another book by the guys from Basecamp, It Doesn’t Have to Be Crazy at Work, in which they share a lot of practical and “mentally sane” knowledge and practical advice on how to run a company, manage a product & teams and other details. The way they build Basecamp can be an excellent example for anyone aspiring to create a good product and company.
I personally share a lot of their philosophy, and their book is a good reminder of how to design a great product. Here are four principles we can all use to design, manage and build better products:
Usually, when people come up with new ideas (in our case for a product) they schedule a meeting, invite the decision makers, present the idea, and if nobody interrupts that person along the way in the first 2 minutes and everybody gets super excited about the idea, then they will work on it. But it is not always the case. Usually, someone jumps in in the first minutes and lets everybody know why the idea will never work. And that’s the problem.
A better way to go about it is to, first, always, before the meeting, have your idea written down on paper. This way you can structure it, so it’s clear. Then you share it with the entire team before the meeting, for it to be considered. No feedback, no reactions, only considered. So people can take time and think it through.
Then, when the meeting happens, nobody interrupts the presenter. And when it ends, people can take the floor and give constructive feedback. Feedback that guides the person or builds upon what was said and not one which kills the idea. And then, after the meeting, you take time, a couple of days, or weeks (you choose) and think it through. This way, you take actual time to process what was said and discussed.
Why not do it directly during the meeting and save some time? When you gather all together and discuss the idea, you can’t say that you think individually. It will most likely end up in a debate in which everybody tries to defend its own piece of the pie. So taking time, and thinking it through, alone, is the best way to go.
This approach is similar to Braintrust, used by Pixar. Braintrust is a type of meeting run by Pixar when they work on a new movie. The goal of which is to leave aside your roles, and during it offer guiding feedback to the person who is presenting the idea. Rather than killing it with criticism on why it will not work. Or better said:
During the meeting, there is no authority. This is important because the person who is in charge of the project/meeting does not have to follow the feedback. After a Braintrust meeting, it is up to him/her to figure out what to do next. These meetings are not top-down or do-this-or-that. By removing the authority from Braintrust meetings, you give people the flexibility to be creative.
During a Braintrust meeting, Pixar doesn’t want to be prescriptive but offer honesty and in-depth analysis. Braintrust is benevolent. It wants to help. And it has no selfish agenda. But in a typical meeting with a competitive environment, you would generally compare your idea against others, turning the discussion into a debate that must be won or lost.
A great approach at Basecamp is doing product work in a team of three which is usually made of two programmers and one designer. This way you have less mass to your decision making process. And the benefits to this type of approach are countless. Beginning with the fact that, less people you have on the team, more involved they will be. You will spend less time on misscomunication and meetings, make faster decisions, and spend less resources.
And it does not matter if you are a startup or a multi billion corporation, a team of three can be done at any size. The approach of working in three was applied not only by they guys from Basecamp, but also by those from Nike. For example, in the article Why Small Teams Win and Bigger Ones Fail, I gave the example of how one of the best Nike products were created in a team of three.
HTM is the name of Nike’s experimental design project launched in 2002. HTM takes its initials from the first names of its three collaborators: Hiroshi Fujiwara, Tinker Hatfield and Nike’s CEO and designer Mark Parker.
What was the role of HTM? Three designers and the primary decision maker got into a room, left aside their daily routines and worked on the reinterpretation of existing product designs to the development of new ones. This is also a fantastic example of how designers can work together with the CEO of a company rather than just receive orders on what to do.
Working only in three allowed them to have all the time in the world and an accelerated production process, which is impossible to realise with a standard company process. The quick pace from development to release is otherwise unthinkable for an enterprise of Nike’s scale.
Adding more, increases mass. If your goal is to reduce the mass, then adding more is always a problem. Because it requires someone to manage the team. But when you are in three, you can improve the communication, you get all the time and focus, and you are able to design and build something great, without any interruptions. You don’t lose energy on processes and approvals. More people will always make things more complicated.
It’s of course challenging to build new products or features in a team of three, but that’s the beauty of constraints. There’s a widespread myth that to get a better picture you need a larger canvas. Yet every creative knows this to be untrue. Too much freedom can lead to mediocrity. Without boundaries there’s no incentive to break through them. A creative person, with limited resources, will not have any issues with innovating or creating something great.
Change — something humans don’t love and are uncomfortable with, and this applies to products too. Especially when we make people use our newly released version of a product when they don’t want or need it.
Let’s say that you are working on V2 of your product, and are about to release it. What if there are people that don’t want it and are comfortable with using the V1 of your product? Most companies don’t take this into account, because they think: “But V2 is better, why would you not want to switch?”
When Basecamp was working on redesigning their app, halfway through their process, they asked themselves “What if people don’t want to move to a new version and they are used to their current one?” Because moving from V1 to V2 means migrating the data, converting formats, and presenting an entirely new user interface. And they decided not to force the migration. Things won’t change for current users, and the change was optional. This way the company saved resources, time and kept customers happy.
And it’s not only Basecamp who took this kind of approach. Another great example is Freshbooks — all-in-one small business invoicing and accounting solution. In this case, I was on the other end, as a user, and experiencing it myself.
When they improved the product and released a new version of it, they made the transfer optional. So you could switch at any convenient moment to V2. Moreover, you could switch between versions, by keeping your data intact, and see which one suits your needs better. You could play around and test things out. This way you put less stress on your customers, save them time and keep them happy.
And if you wonder, after playing around with the new version I switched to it in a couple of weeks. But this happened only because I had the time to play around with V2, get used to it, and once I was convinced, I made the switch.
If you have been following my articles, you know that I wrote a couple of them about how easy it is to get lost in a process and always throw more at a problem. More time, more resources, more people, more testing, more debating and so on. What we all miss is the dedication and discipline to deliver a product on budget and on time. Then launch it on the market and learn from it.
Instead, we debate endlessly whether we are implementing the right features. Whether this is what’s going to make our product unique. How is it going to fit in the grand vision, what about the roadmap and other energy draining stuff. And you can continue questioning whether you are doing or designing it right or delivering something customers want. But unless you will launch it on the market, you will never know. No surveys, no user testing in the labs or closed environments, no user research will tell you if you designed something great.
And this happens is in any industry, whether you are shooting a movie, designing a game, or architecting a building. You don’t know if people will love it, use it or buy it unless you launch it. You can have internal meetings, debates and discussions about it, but that’s all subjective and can quickly go the wrong way.
The guys from Basecamp even take it to the extreme. They don’t show anything to their customers before it is launched. They don’t do beta tests. They don’t ask people what they would pay for it or what they think about the product. They launch the product, and the market will tell them the truth.
I was having a similar conversation with a friend of mine who works in the game design industry, and we were talking about how people who designed the greatest games ever launched, didn’t know anything about what they were doing too. Of course, you have techniques, human psychology, past releases, mistakes learned, and other elements that allow you not to screw up. But unless you launch it and take a risk, you never know if it will work.
In the end, it doesn’t have to be crazy when you want to build a great product or feature. If you have the discipline and focus on keeping it clean and reducing the mass, you can design something great. But you won’t solve anything if you throw more at a problem.
If you want to know more about how the guys from Basecamp work, you can listen to one of the podcast episodes I did with Ryan Singer, their head of strategy. Also, you can read other related articles:
Principles For Designing Better Products
Research & References of Principles For Designing Better Products|A&C Accounting And Tax Services
Source
0 Comments