I have learned a lot over the past 5 years working at GetHuman, but as far as product development goes, this past year has been like drinking from a fire hose. Besides launching two new products, Swish and VendorSmith, as well as working on several others that haven’t come out yet, I have spent a lot of time thinking and discussing product development strategy with my amazing team members.
The linchpin and primary driver for many of our product discussions is Tim Noetzel. Tim is a long time designer and UX expert that has a number of amazing publications (like this Lean UX course and this awesome article about Data-Based Personas on Smashing Magazine).
Here are the top 5 lessons I have learned from my good friend, Tim, about Lean UX:
- You don’t know anything for sure. You have a theory. You can test that theory to see whether it is true or false.
- Good design starts with a good design process.
- Every team member should be involved in product design at some level and treat UX as a first class citizen throughout the organization.
- Until you achieve product-market fit, avoid heavy investment in development. Try to validate theories and design your UX through a series of small experiments. You should be able to do this with days of development, not months.
- You don’t need every single person to have a great user experience. You just need to focus on your target audience/persona. That means first figuring out what your target persona is. Once you have that, it becomes much easier to create the best possible UX for the users in that persona.
I have been thinking a lot about Angular recently as I prepare for my ng-conf 2018 talk, Super-Powered, Server-Rendered Progressive Native Apps. This blog post is a by product of that thinking.
I recently posted an answer on Quora for the question “Which one is better: React + Redux vs Angular 2?” and I wanted to highlight one idea I had for how a company can make this decision.
The basic idea is that there is essentially feature parity between Angular and React so really it is more about aligning with the framework that will make your team most productive. To that end, I came up with a way to evaluate this.
Jeff’s “Angular vs React” Evaluator
Let’s say we have two teams: a red team and blue team. I am going to go through a few aspects of software development and for each one, you should assign a point to the team that is most like your team.
View on Framework Scope
- Red Team: Prefer an all-in-one solution; framework should ideally do everything;
- Blue Team: Each library should be limited to just one thing that it does extremely well and leave it to use to piecemeal together the best overall solution
Backend Language Background (i.e. how most people learned to code)
- Red Team: .NET, Java, C++
- Blue Team: Ruby, Node, PHP, Python, Pearl
Attitude Toward Abstractions
- Red Team: Abstractions are mostly good; fewer lines of code the better
- Blue Team: Abstractions are mostly bad; better to be explicit even if there is more code
- Red Team: Most of our existing apps are in AngularJS 1.x or Angular 2+
- Blue Team: Most of our existing apps are in React
Tally up the points. If your team is most like the Red Team, then go with Angular. If your team is most like the Blue Team, then go with React. Of course this is not perfect, but I think it does give you a good guideline for making a decision between Angular and React.
It is extremely common for all of us to assume we understand how other people think. We may consciously admit that we don’t know for sure, but in order to function as human beings we do have to make certain assumptions. For example, when you a run into a longtime friend, you may assume that person is going to give you a hug or high five and not punch you in the face. But…you could be wrong. Perhaps you don’t know everything (ex. someone told your friend that you kicked her dog) or…perhaps that person doesn’t think the same way you do.
It is this second reason that I find most flummoxing and disturbing at times. The thing is, as much as we all admit that everyone think differently, we also can’t help but assume there is some base level of logical thinking that is common among us. In other words, we all may like different things and have different histories, but logic is logic. Logic is an absolute truth just like math. Each person should be able to reason through a problem in the same way if given the same facts.
Unfortunately, it doesn’t work that way.
The reality is that although there is a common way that most people reason through problems at a most basic level, there are many people that are just wired differently. You can give certain people all the same facts that you have and walk them through your reasoning and logic step-by-step, but they will come to a different conclusion. This can be extremely upsetting and disturbing. It can feel like you are living in a different reality than that person because they don’t adhere to the same fundamental laws of the universe as you do.
I wish I knew how to deal with this situation. I don’t. Like most people, once I realize I can’t find common ground from a purely logical basis with someone, I can’t help but withdraw and walk away. I am not saying that is the right thing to do, but it is better than the alternative which is trying to jam your reasoning down someone else’s throat.
One last word of caution, though. When you get into this type of impasse, you should try hard to NOT assume you are the one that is “right” and the other person is “wrong”. Sometimes that may be the case, but many times upon further reflection I have realized that I was actually the one that had a flaw in my logic and reasoning.
To recap in short:
- Always try hard to understand other people
- Work with them to try and reach some common ground of reasoning and logic to build from
- Even if you can’t understand the other person’s logic, seriously consider: “What if I am actually wrong and he/she is right?”
- Finally, if you can’t find any common ground and the topic can be avoided, walk away
Of course…if you get to #4 and it is an important issue that can’t be ignored then that is a whole other issue for another blog post in the future.