I like to work with small teams.
They don’t have all the resources.
Neither do they have all the knowledge.
They do make a lot of mistakes.
What I like about it is the type of people involved.
They are ready to work against the odds.
They invest their time and their own money because they believe that they can deliver. Even if they have never done this before.
Often, when I get approached to do design for enterprise software there is already an existing product designed by the person who came up with the idea. Most often a business person. Solving a business problem or capitalizing on the missed opportunity.
In this first version of the software, they don’t really care about visual design and UX. They are looking for proof of concept.
They hire a few developers and get to work. Straight to code.
Probably the biggest design effort at this point is picking some framework with predefined UI components because most often “serious developers don’t like to write front-end code”.
Make this first quick & dirty version good enough, so they can start to use it or sell it.
The tricky part is…
To not upset the developers in the process. Don’t make them change too many things.
If the product is already in use, don’t move around the features so much that the existing users get annoyed.
Make it so when they have to add a new feature next time, they don’t need to call you to design it and can still get a decent result.
Improve the experience.
It’s a great way to do a proof of concept. Especially for the technical part.
You save time by skipping the standard process and jumping straight to code. Hire only a few people.
You also save money by cutting on the process and hiring stuff.
It’s pretty compelling from a business standpoint!
It’s hard to argue against, but let me try.
Where things get complicated is when the software owner smells the money, so to speak.
In most cases, they want to build on top of what you already have.
Not the best decision from the production point of view.
This will be difficult to scale. And the main purpose of a software product is to facilitate scale.
This first version of the product is made to work. And there is a big difference between something working and something that brings value.
The fact that it is working is giving you an advantage when you are the only solution. The moment there is competition your product becomes the ugly, difficult to use option.
If you are building an enterprise app for internal use you can ignore the UX and the visual design. But even then consider this. Nowadays ordinary people have big expectations from the user experience. Digital products such as Facebook, Youtube, and Instagram set the bar high for what is expected. A year ago my 3-year-old daughter smashed my brand new iPhone to the ground because Youtube buffered for two seconds.
Giving your employees barely usable software is like giving a cook a pierced pot and expecting a juicy meal. The good stuff is going to leak.
And you are going to chew on dry rubber and pretend you like it. Mmm…
When you are building a SaaS or a PaaS the steaks are even higher. If people pay, great UX is expected. And they get mad when it is not there.
I know what you are thinking…OK, we will hire a designer to make it pretty, so it’s easy to sell.
Well, this will help a bit but not much. What is more important is to think about ease of use. Focus on solving the fewer problem is better than trying to solve all your client’s problems somehow. The beauty of digital products is you can track every move in your system. See what they are using and scrap the rest. I know, it’s easy to say. But try it on a small scale. Measure results and decide for yourself.
Having too many features is probably the most common problem when the boss and the devs are designing. This is even a problem with products with big design teams. The appeal of adding one more thing to get more business is strong. It’s relatively cheap to develop if you compare it to the potential profit.
But feature overload is also how products die. How many multi-purpose products do you use on a daily basis? How many of those come with all the features built-in and how many are just with the basic features and you buy the rest if you need it.
My point is… don’t try to shove everything together. Nail down the basic features and upsell the rest. As a different product or an add-on.
I went on a bit of a rant about the cons there, but I hope I got my point across.
In short. It works sometimes if you get the right people on your team. But most often it doesn’t in the long run. It’s fear to say — in my experience.
After you have this first proof of concept. Okay, give it to some clients but with the purpose of gathering some insights. Then start thinking about rebuilding it with scale in mind as soon as you can. The longer you wait — the harder it gets.