Anyone that has ever tried to create an online product will tell you that if you don’t apply an agreed upon process for your team at the beginning of the project that it will quickly become a massive quagmire of technical debt and layer upon layer of useless and hard to use UI. Ultimately resulting in the product failing.
Think of it like prehistoric animals plodding along a tar pit. The more they struggle, the more they get stuck.
Having a process in place where you put your team working and communicating to their strengths is the essential ingredient for achieving success on an online product and navigating your way out of the tar pit of failure.
Here are a few simple rules to follow:
Enjoy Creating Problems To Solve.
Design and Develop Using a Standardised System.
Test. Test and Test Some More.
Take Your Time.
Understand Why Failure Happens.
Enjoy Creating Problems To Solve.
You can create problems to solve by simply being observant of the world around you. The way you interact with anything can always be slightly improved or optimised to better suit the needs of yourself or other people. The most inventive solutions usually come from people who don’t adhere to accepted norms.
Take for example the task of providing light in a dark room. For centuries people used a naked flame to light up a room. It wasn’t until Thomas Edison came along in the 1800’s that he decided that by channeling electricity through a tiny conductor inside a glass bulb that he could achieve a far more effective result for illuminating a room.
As a user of the internet, surely there are interactions on the web that you have where you see room for improvement. Start by asking questions like: How can I save time for myself? Is this web page helping me to achieve my task or is it hindering me in anyway? Soon you will start to identify problems, and then you can begin to solve those problems.
Never stop creating problems…..Ever..
Design and Develop Using a Standardised System.
Once you have a problem to solve, and an idea of the possible solution, it’s time to begin designing and concepting your idea. As a rule of thumb, Design comes before Development. The reason for this is that design allows you to cover a lot more ideas in a shorter amount of time. When we say standardised system we usually mean best practises.
In the early stages of the design process uses practises like; brainstorming, heuristic analysis, user flow & journey maps. These practises allow you to expand on your core idea and also to validate it as a viable solution to the problem you are trying to solve. In the design world all these practises come under the area of User Experience [UX].
Once you have validated your idea as something worth pursuing you can then begin to design and shape what your idea will look like. Concepts or Mockups can be generated to a high standard by a qualified User Interface designer [UI]. A UI designer will know to use a pre-existing user interface library because they know it will not only keep their fellow developers happy, but that by using a interface library your product will perform as it should over multiple devices and multiple web browsers. it’s kind of like constructing a house of cards with glue, some consider it cheating, but the majority consider it smart.
Developers generally like to have a set of instructions to follow. Personally this author has never come across a developer who is bad at assembling IKEA furniture. It is the responsibility of the UI designer to provide his or her developer with a clear set of instructions for assembling the idea into a web interface. Developers too will use standardised programming languages, at the time of writing the most up to date is reactjs. Using a standardised programming language allows a developer to quickly generate the interface and release it onto the web where it can then start to be used.
Test. Test and Test Some More.
A lot of big companies like to internally test a new product before they release it to the general public. Smaller companies and individuals shouldn’t do that.
The reason you should release your product to your intended userbase is because your users will provide you with frank and concise feedback on what they liked and what they didn’t like about your product. You can then use this feedback to improve your product through small incremental changes, a nice knock on effect of this is that you will then begin to start building a loyal user base because they feel like their voice is being heard which makes them feel valued.
You should always be testing your product against the people who matter, your customer. If you don’t, your product will become stagnant.
Take Your Time
As your product grows, as your revenue grows, as your customers grow, the natural human reaction is to increase staff exponentially to handle the growth. This is a mistake.
A good example to explain this is making a toast. If there are 2 people making a toast, they stand up and clink glasses. The toast is made.
If there are 20 people participating in the toast, each person has to clink glasses with the other 19 people [ 380 clinks ], just to achieve the same toast.
How does this apply to software design? Well, if I have to communicate with 19 other people as opposed to just 1, it takes the process a lot longer to complete. When you have a big team, outside factors such as delegation of tasks, team cohesion and project management become huge factors of time. Over time this turns what used to be small agile team, into a big clunking dinosaur in a tar pit.
Take your time with a small team, revert back to UX findings and order your tasks to be completed by how important they are to the core of your idea. It takes time to slice up and order these tasks, but it is time wisely spent. This is the true implementation of an agile methodology.
Understand Why Failure Happens
Humans are inherently optimistic, especially when were talking to a boss or a manager. We mostly mess up on time management. We confuse effort with progress. We don’t know how to say no. We monitor project status poorly and when we fall behind, we add more people!
Accept that you are human, accept that the problems you are trying to solve haven’t been solved before. It takes time and patience to break new ground and deliver an idea to an intended user.
If you understand the reasons why you fail, you can spot the signs and take action to avert the failure before it happens.
Conclusion
This article only briefly touches on a school of thought from a book called ‘The Mythical Man Month’ — written by Frederick P.Brooks. You can download and read the book in it’s entirety by clicking on this link: Book .