Once I read an interview with Ryan Singer, the Head of Strategy at Basecamp, and the interviewer asked: “How can you get to a stage where things are just running smoothly? Where do people go wrong?”. To which he said that — people struggle with getting started not with the process or the product. They struggle with the transition from exploring to execution. Then they strive to remain focused on a few pieces, rather than jumping and getting excited from idea to idea.
At first, it may sound weird — how can design commitment be one of the basics? Building a product is part of the process, and we must understand that it is not less significant than making our product “simple” and usable for the user. The building and testing stage is when people usually get tangled into details and other office politics. And never deliver something tangible.
We continuously debate which ideas are better or how many other great opportunities there are. We strategise, endless meetings, tons of sketches and designs, we do everything but not delivering something. And it all ends up with a one year roadmap to which you can’t add or remove anything. Because of all the effort, you have invested. But there are a couple of things we can do better when designing products.
No matter how big or small your company is, remember that it’s always great to have 2–3 people who wrestle with a problem. And then focus your energy on 2–3 features to which you can dedicate your time and effort.
Let’s say that you wish to make changes to your product, or refresh a feature, or add something new. First, there’s no need to involve the entire company in the process.
For example, the guys from Basecamp always make a team of 3 people (1 designer and two developers) that will work separately from the entire company on a project/feature. And the most interesting thing is that nobody from the company is allowed to disturb them or ask for requests (even if the house is burning). They are granted full focus and liberty on their time management.
This way, you preserve the creativity of a team and don’t allow the bureaucracy or other politics to mess with their process. But next comes the idea of committing to a feature/idea. And here, during our podcast episode, Ryan Singer said a good thing:
Every day you are going to come up with new ideas that are great. But can you imagine a real-life situation where this matters? That’s where many ideas fail.
As mentioned in the previous article, asking questions is what is going to make your way clear. In this case, the question from above will save you tons of hours of debate. So once you chose an idea (feature) you want to work on for your product, and dedicated the team, now you have to make yourself a promise. A promise that you will deliver something in a certain amount of time. Let’s say that you choose “Deliver feature A in one month”. And that is a contract with God. You deliver the feature in a month, and not more.
And staying focused on something. Seeing the concept through and getting raw feedback and data. Did it work? What did we do wrong? How can we do better next time? Instead, we deliver half-assed products that don’t bring value to the end user.
Once you realise that features or ideas for products are like babies, you will see things from a different perspective. You can adopt as many kids as you want, but the problem lies in — are you able to see them through? Through all the stages of prototyping, testing, iteration, testing, launching? That’s where we need to understand that more is not always better. Sometimes delivering, one but great feature is much better than 3 and mediocre.
This means you will have to live with uncertainty. Once you commit yourself to deliver something, you have to deal with uncertainty. And tell me whatever you want, but people hate it. And I know how it feels because it does not always work and the chances are that you will fail. But in product design, uncertainty is like your brother/sister. You can ignore it, but it will still be there. Living with uncertainty is something you have to embrace during and post-project launch.
For example, you may have a bad menu bar for your iPhone app. But it works. It doesn’t look fancy, sleek, and even technically, it could be improved, but it does the job. So you will have to choose — will I focus my energy on improving it or will I live with uncertainty and focus myself on other important stuff for my user? Like, enhance the speed and reliability of the app. These type of questions will come a lot during the design process.
And sometimes, you may leave that menu bar as it is, and weeks will pass by after post-launch. And only after a certain period you would get the idea of how to improve it, rather than creating a subjective visual improvement. The design is doing the right thing without committing to the internals of that design. As long as you can see where that boundary is, then it’s all about having the discipline to figure out the things that are important right now. And to give the things that are not clear space to develop later on. That is living with uncertainty and having the courage to trust the process.
Some people say that you should never do the visual part in the beginning because it slows down the process. But what they get wrong here is not that you must not do it, but what does the user value most? If it is pixels, then you must do the visual first. If not, then you should focus on the technical part or other essential parts.
Let’s say your project is to do a website for promoting a book. If you had focused only on the technical part, you would have missed a critical thing here — the visual component is more important. It plays a significant role in selling that book. And you will lose a big opportunity if you would have focused on other stuff than making it look great and sellable.
Design is about balance and context. You can’t solve a problem with the same approach all the time.
A customer is trying to make subconscious progress when using or buying a product or service from you. And our job is to define that progress and give it to them. The progress could be technical, emotional or even social. You should remember, that there’s no one right way to do things. You have to decide what matters for each project and your users.