Lessons from a failed idea
I am a software developer that has a couple of small notebooks around the house where I write most of my ideas and thoughts about new projects I would like to create. Here’s the story of how I decided to build an idea without thinking about all the needed UX/UI/design system skills and when that turned out to be a problem.
This story would be way more glamorous if I talked about a simple idea that popped into my mind on a casual day and made it into a resounding success. I know this type of stories, I read them as well. This post is not about that, because I haven’t experienced it yet. We rarely read about failing projects, because some might not consider it to be valuable. Well, for me it is. Representation is always valuable.
I have worked on products that were a success, but they weren’t my projects. And more importantly, I don’t know how many years of failing it took for that idea to succeed.
And the idea is?
The first idea that left the cosiness of my computer and version control, is “Plan Our Wedding”. You guessed it, it’s a wedding management web app. I wanted to use one tool that can help myself and my partner manage everything about our (not exactly) small wedding that was coming up. I wanted to have privacy (arghhh!!!!) and to communicate mostly online with our guests before the event.
Our planet has enough problems, so I didn’t feel the need to bring paper invites into it. I know they wouldn’t get recycled by everyone. In full disclosure, we still made some, specifically for a different generation that doesn’t want to use technology for this type of event.
This is the first project I dedicated an entire year to. I learned so much throughout the whole process and I know I wouldn’t have had the opportunity if I was working a 9-5 job.
My game plan looked like this:
- I already had the idea. It’s a wedding management tool. I was the first client, so it was fixing my own problems.
- Document what technologies to use on the frontend side. a. Why did I choose React.js? It wasn’t a personal preference, I chose what was popular on the European Job market at that time. b. Why Java 11 on backend? Because I have worked mostly with Java, either on backend or native Android. I was comfortable with it. SpringBoot was a clear choice because from 0 to production it takes a short amount of time.
- Naively created some milestones to get a sense of what timeline I was looking forward to. On backend side, that was easier, on frontend, it was not.
- Draw in a minimal way what I would like each screen to look like.
- Create a structure for the backend side. I wanted to write and run tests: unit tests and integration tests. For this, I made different profiles so I don’t mess up my production database. I wanted to manage my database properly, be comfortable deleting it and getting the structure AND demo data back in 1 minute.
The initial plan was based on everything I thought I knew about creating a project. It was intentional and actionable, I knew what I was working on each week. I didn’t count my hours specifically, but I didn’t work too much over the usual hours. One big difference was that I was way more concentrated and less distracted by meetings or random chitchatting in an open office structure. I was changing hats often, I was either the developer or the project owner. It was important to do this because I wanted a product that helps with self-managing a wedding and I didn’t want to stray away from that just to try some cool technical feature that wasn’t helping.
As time passed by, my features were implemented and the dashboard started to take shape. I didn’t get back to modify my plan, because a lot of times I redid some parts, rewrote some code. It was either because what I knew was outdated and a better way to do it was already available, or because I didn’t see the feature in the same way. First reality check with multiple users was when we sent the RSVP invites to friends and colleagues.
It’s something very real and raw when another person uses your application. All the «this isn’t important, I’ll fix that another time » moments became « this IS important, it doesn’t work for the users». They don’t know the intricates of that, and why should they? If you send them a form to complete, they want to complete that form.
I used a free tier on what services I could because I didn’t have money to spend on this. In reality, I did, because I had enough to pay myself a base salary, but I didn’t think of it to be important at that time. On design …oh… I changed the ‘design’ at least 3 times. What I didn’t recognise is that I needed to study UX/UI and practice a lot before I can create a design system on my own. For this, I definitely didn’t have enough money, even if I wanted to.
The first user that wasn’t us or our invitees, was a friend that had a wedding that same year. They didn’t have time to do much on the platform, and realistically I can understand why. The web app worked for me because I created it, but for others, it wasn’t user friendly.
I can recognise that at this moment I should have reset a bit and think of my actionable plan of increasing the quality and user experience. And I should have done user research. A fancy way of saying that I should have talked to my one and only user about how they use the app. I could have worked more ‘in public’ and write about my journey. Instead, I wallowed that I failed and took a few weeks away from the project. On top of that, I started a small new project just so I get a positive mindset that I can still create something. In hindsight, I shouldn’t have done that. After some time, I regained my enthusiasm and I was ready again to continue my work.
Retrospect and pain points
That year of learning and creating something from scratch is on the list of best investments in my career. Every time you can learn something new or, and this is equally important, you get the chance to re-learn something you think you knew, take it. Do the work. Invest in your own career and don’t expect others to do it for you.
I learned how important UX and UI is for a product. If your product is not easy to use, then you need to fix that. If you are lacking some skills (realistically there must be at least something that is not in your strong skill set), and you can afford this, delegate to other professionals to help you out in your journey. Because from I can tell, it’s a journey and it can be a long one. Read as much as you can about every question that pops into your head about project management, web accessibility, project architecture, testing, user research etc.
What about you? Do you have a failing idea story to share?
Notes mentioning this note
There are no notes linking to this note.