I used to be a development infrastructure team leader. Part of my job, as I decided it to be, was to provide tools for teams to communicate with their customers and provide tools to build better and more relevant software.
The team itself worked like a startup company within the organization. We didn't force people to use any of our solutions – we tried to make them thrilled and excited about them, so they would support our products and use them with their own will.
While I had success in some cases, there are couple of failures I still carry with me in my head, and lately I figured out that they all share the same problems.
I worked alone
Most of the time, I worked on these tools for too long, alone. They all began with me starting to hack at night, and evolved to real projects, with no one but myself writing them with me. Although it was very fun to begin with it, working alone on these tools wasn't rewarding because I had no one to be excited as me about the projects.
It taught me that demo time is important. Make time to show your projects to your colleagues. Many team leaders, with me included, had this problem that we haven't asked for a demo. I just didn't wanted to interrupt my employees. Just agree on the demo on a specific time, and make it seven, eight, fifteen minutes long demo.
It can be a fun thing to do, and the team can learn and get inspired from the act.
I had no real users
I always seen myself as the user, when I clearly wasn't. This is a basic rule in UX design: thinking about myself as the user makes me to make wrong assumptions about the tools and the way I solve the problems. Hell, I am sometimes wrong about the problems themselves, without consulting with a real (or another) user. One example is my love for command line utilities and VIM in particular, while other colleagues are terrified by it.
Go out for a walk, think about your problem and characterize your users. Who are they? If they're your coworkers, talk to them. If they are 23 years old bartenders, go to a nice night out with a pen and a piece of paper and just talk to a bartender.
The important thing here is to talk to another human being. Even if you are a future user for the app, you should understand what to address first. Many times we see the big picture and we want to solve it from one end to the other – but sometimes providing a really simple and basic tool is enough for start.
Providing a good MVP to your users is the most important thing. It might feel like a simple CRUD application, but it might solve a tiny bit of the problem. The only way to have a good MVP is to understand what HAS to be in the app and what is just NICE TO HAVE for now.
I tried to satisfy others
I showed one of the tools to my boss. The tool was a micro-blogging/blogging/mailing list tool, making teams interact with their customers. My boss took my demo and showed it to some department managers in our organization. They loved it, and asked for a couple of features. One of the features, was to create a “secret” mailing list, changing the solution surface and actually changing the problem that the tool solved.
I just needed to say “no”. However, I'm not used to it, and I really hate to be a no-man, since I really believe in making people happy. Because I had no “real users” either, I thought that my vote doesn't count.
You can't satisfy everyone, so most of the time, you better satisfy yourself.
Now, I know what the vision of the tool should have been: “Open communication between teams and their customers”. Providing this specific vision could make these department managers understand what the tool is for and what it isn't for.
Making sure you address the right problems is an important part of your application. This way you can measure yourself against your competitors and have some agenda why you provide a better tool. You can also get more customers this way, and have people believe in your way, and make FANS for your software. Which is pretty damn wicked.
I was more excited about the code than the product
I saved this one for last. Not that long ago, I worked on a kind-of a Medium clone. In this project, I used Draft.js for the first time, and spent most of the time trying to add images with drag and drop and making a great user experience. I actually wrote an article about Composable SQL in JavaScript while working on this project because I was so thrilled about the way I queried the database.
I'll say it again. I was thrilled about the way I queried the database. I was thrilled how I queried a SQL database, I used for years with Rails, PHP and even plain ASP.
You can't say it's a bad thing, because it is the opposite. Yet the fact that I tried to implement the things I read on Brian Lonsdorf's (drboolean) awesome and life-changing book about JavaScript made me put so much time and effort on the way my code looks and acts. This is awesome for a side project or just testing a feature inside your project, but it should not slow you down in a real project.
If the only thing that excites you in a project is how you write it, well, let me tell you something, the product won't be as good as your code. Try to be a boring programmer. Make decisions about your product and not about your code. Remember that you have to deliver a product. Your users probably don't care about your functional programming skills as long as your product works. They just want to use it.
So,
Is jQuery enough for this app or you should use React? Just build the damn thing, show it to your coworkers and give it to your real users already. That's how you deliver, and that's what you're paid to do basically. 💰
Top comments (16)
Powerful and personal message here, Gal. I really appreciate you sharing your own experiences and flipping them into learning opportunities. Isolating yourself from others has a tendency to lead to a form of tunnel vision. Blocking out others and working in a silo without feedback can really lead you far astray.
There are those who can pull it off, though, but like you say in the article, they are probably focused on the product and are getting early feedback. Or just lucky that their needs match other users' needs :)
I wrote a little about this myself here: codingwithempathy.com/2016/02/23/p...
sorry it took me a long time to reply, I'm not that good with emails!
SOME INTERESTING STUFF YOU HAVE THERE and I agree with your post (obviously). oh, and your blog has the awesomest name I've seen in a while. 💯🔥💯
Thank for your reply buddy!
Found myself, almost the same guy as you in my team. Ideas for tools, coding for coding, python, js an d more, but there is no real users. Yeah, I also love VIM and CLI, also wrote many scripts for myself. Your idea is helpful, think about your real users and their real requirments, not only for code and technique.
Describing the times we fail is even more powerful than the times we win :)
As someone before me wrote, you can't satisfy everyone, but to satisfy the biggest amount of people possible get their feedback and fast. Small batches are the key here. Deliver little functionality in a short time then start to work on the next part.
When I did an internal project for HR department I asked them lots questions about how they want the stuff to work. I showed the how the app worked till now so when something wasn't ok I could quickly readjust without throwing out to much of an app.
Lot's of people are still lost in development because they want to deliver a great product in one go. Bot how are you tell your product is great without people using them in the first place? Get them something to use before you're all ready to go.
When you work alone... have you ever tried to start an inside company community: there are people willing to work for few hours a week for free just to learn something new :) I'd go for that chance if someone gave it to me :)
Thanks for the suggestions Aga! Short delivery spans probably can help for not falling in love with code or features. Community driven projects can also work and I'll try it on my next project! Thanks!!
Your coworkers/users don't give a damn if it's implemented with JQuery or React as long as it's useful.
Exactly.
However, we should also avoid creating tech debt (writing our own mega frameworks on top of jQuery)
Thanks for reading Lluis!
Great post Gal
Thanks Don! 😄 Glad you liked it!
You can't satisfy everyone - that's why we use personas :)
I agree! Unfortunately, UX wasn't a thing in my organization for a long time. There are some awesome people around my organization who try to make this whole area of UX better.
There are still some organizations who don't understand the importance of a good UX designer 🤷🏻♂️
Indeed. Writing code without a clear product definition isn’t as exciting as free-hand tattoo artist, unfortunately.
Thanks for the nice words David!
Great article! I couldn't agree more with the things you said. :)
Haha "couldn't agree more... unfortunately..." 😜
Thanks, David!
There is one thing for sure: you didn't fail to deliver. At least not with this post. Thanks for the great article.
Oh! That's sweet!
Thanks Markus 😄