Forem: Chinmay Joshi

Help me understand unpaid internships!

Chinmay Joshi — Wed, 29 Apr 2020 00:12:00 +0000

Disclaimer - Using this discussion thread, I am not promoting paid/unpaid internships. I am not justifying right or wrong between any type of internship. I am simply trying to understand what the DEV community has to offer.

I feel there are many occurrences when students or individuals seek an internship; while pursuing education, career change, or maybe some other reason.

To my understanding, the internship is an opportunity given by the employer where the employee or an intern for a specified tenure (a month, 3-months, 6-months, or a year), where more experienced individuals mentor an intern. Some employers provide paid internships; some employers offer unpaid internships. Here are a couple of examples of how an intern position might look like in different companies. If you find some other examples, please do post them below, I will update the list.

Google - User Experience Design Intern, 2020 - link
Wix - Playground - link
x company - Product Designer Intern

In the mentioned examples,

We all know, Google is a very well-settled company in the industry, financing and planning an internship is a pretty easy job for them.
Wix is another mid-sized company, providing an extensive and pretty informative program for a solid career headstart. Of course, that program is unpaid, but the return on investment would give a headstart to one's career.
In the third example, we can see a startup company working on a product that's not in the market yet. The same company is looking for an unpaid-internship where they would be treating an intern as a full-time employee, which is an excellent opportunity for an individual to get his hands dirty with real-time products.

I want to ask the DEV community,

Is it okay to pursue an unpaid internship? And how would you justify an unpaid internship? How do you measure the worth of an internship?
And, is it ethical for an employer to hire an unpaid intern?
How would you convince the employer for a certain amount of pay?

Should UX designers create User Personas?

Chinmay Joshi — Wed, 26 Feb 2020 01:24:34 +0000

Cover photo by Patrick Perkins on Unsplash

A persona, in user-centered design and marketing is a fictional character created to represent a user type that might use a site, brand, or product in a similar way. Marketers may use personas together with market segmentation, where the qualitative personas are constructed to be representative of specific segments. — Wikipedia

What is a User Persona?

A user persona is a way to create a board that explains minute details about the user who would potentially use the product as a stakeholder. The user participating in the user persona is imaginary, with characteristics persisting in our real target audience.

User persona usually consists of the following things - name, family status, educational background, professional background, environment conditions, psychographics, his likes, and dislikes, needs, and pain points.

The primary goal of creating a user persona is to understand the needs, behavior, and goals. It's a way for a UX designer to step into his stakeholder's shoes and understand what he feels about certain things.

Once a great man said,
Great designers don't fall in love with their solution. Great designers fall in love with the problem. — Jared Spool

Deriving from that, creating the user persona is the best way to understand the user's pain points and problems. Best solutions are obtained by keeping the user's needs at the core. User personas are created based on substantial research, unifying qualities, and pain points of the target audience.

Usually, there is one persona for every type of user in the system. For example - let's say we are designing a system for connecting mentors with mentees, and there's an onboarding process for mentors that would be accessible to moderators. So in this scenario, we'd be having three types of user personas, mentor, mentee, and moderator. That would help us step in the shoes of every user who would use the platform. Before creating the user persona, it is mandatory to have a clear vision about the product's future; otherwise, it would potentially affect our user base.

To create a user persona, it involves many steps and collaboration of multiple research factors. Here are a handful of strategies to create meaningful and comprehensive user research.

User research - once we define the target audience, the next step is to reach out to them with the set of questionnaires. Prepare for open-ended interactive questions, and interview the audience until you start listening to repetitive answers to your questions.
Find characteristics - Through the user interviews, we get quantitative data, and the later stage is to create qualitative data.
Find pain points - Establishing characteristics would help us find the common factors amongst the audience. But once we search for the pain points, unify, then we get a bigger picture of the problem we are trying to solve.
There are a couple of more factors that we can consider while we establish a user persona, such as their needs, goals, and personality. Combining them in a user persona creates a comprehensive picture of how the end-user would look like.

Now, we established a pretty decent idea about the user personas, so let's discuss a couple of advantages of creating user personas,

Showcasing the audience - User personas are a great way of showcasing the basics about the audience. Such as gender, age, occupation, location specifics, etc. Using which, any person without prior knowledge of UX design can understand the audience.
Understanding the behavior - User personas are a great way to showcase the patterns and behavior of our audience. For example - A user persona of a shopper would showcase where he likes to shop, how he wants to buy. How much he spends on one spree.
Gain empathy about the user - Human is a self-centered living organism. We tend to care about ourselves before caring about others. While creating a user persona, we focus on the user's problems and needs. We focus on how we can solve their problems rather than assumptions.
Appropriate decision-making - I won't say we would make the right decisions all the time while designing a product. Sometimes things might go wrong. But, with the help of comprehensive user research and detailed user persona, we would be able to make sure there's less possibility of things going wrong. Every decision made will be made based on the user's needs and pain points.
Clear discussions and meetings - When it comes to discussing the target audience, it might get time-consuming and confusing to decide in which direction the conversation must go. The meeting can be with subordinates, stakeholders, marketing managers, or even a family person; A user person can act as a mediator to convey meaningful decisions and conduct meaningful conversations.

Personas are distilled essences of real users. With personas, we build empathy with target users, focus on their world, share insights/knowledge with other stakeholders to gain consensus, make defensible decisions reflecting the persona' s/user group's exact needs, and gauge our designs' effectiveness through their eyes. - interaction-design.org

How to create a user persona?

Well, it is straightforward and logical when we have a thorough research. At this stage, we have identified the target audience and have qualitative research statistics. Ideal user personas should be goal-oriented, communicating an imaginary scenario flowing through every aspect of it. Goals would help us make decisions, and the situation would help us maintain the empathy and emotional connection with the target audience.

Make a strong hypothesis, with the help of initial or secondary research. A hypothesis will help us define a persuasive problem statement.
Find a scenario - a scenario relating to the product's problem statement.
Construct useful details about the person who would be participating in the persona. These details have to be imaginary. Create a strong personality that would seem normal and acceptable by everyone.
Validate our scenario with the imaginary person we just created. Make a strong selling story. Why? Let's say we are designing a platform for online apparel shopping, and the user we described is a 60 years old grandmother living in a small city. This story would make less sense. We just created a couple of loopholes that'd not validate our story.
Think about common pain points.
Define his needs and establish if they are satisfied at the moment or not.
Define user goals - Think about the user's interaction and the things he will need to fulfill his requirements.

Examples

Here's a website which provides good examples of user persons - link
And, Invision has a comprehensive guide in order to create user personas - link

Conclusion

The above steps will generate a fundamentally strong idea about our target audience, which can be part of any decision. We can convince the stakeholder and investors.

By considering all the factors mentioned above, a user persona makes a bold statement in the design process. Avoiding this step can cause a lot of damage to the decisions we would make. One wrong decision can lead to many failures. When the target audience uses the product, they should feel comfortable and confident. Also, user persona is a friendly interface that can be part of any conversation throughout the process. It's fun, interactive, and helps construct our research. Hence, it should be mandatory to have a user persona as a part of the design journey.

More Resources -

How did I create my first personal website?

Chinmay Joshi — Fri, 09 Nov 2018 18:01:56 +0000

With the little bit of smart work, countless design iterations, a handful of resources, awesome inspirations, 55 git commits, page beautifying illustrations and subtle animations. Finally, my website is presentable. Well, this is just the beginning. In the future, the goal is to achieve near perfection with the overall design and user experience.

Constructive feedback is welcomed and appreciated. Here's the link to view my website - chinmay-joshi.com

Since the beginning, I used GitHub to host my codebase and website. You can check out the code here. According to the Git history, the first commit was on September 6, 2017. That means it took me over 430 days to make it publishable.

There are three primary reasons I am writing a blog post -

Show off what I have done.
Get feedback from awesome developers like you.
Reach and connect with like-minded develolpers.

What I fancy about the website?

1. Day and night mode -

The background colour changes according to the time you are visiting the website. If you visit after 7 in the evening, you can see the night mode, and it will be active until 7 in the morning. There's a button to toggle between the day and night mode.

2. Round shaped transparent glass effect -

I created a semi-transparent layer of a glass looking element, with the hidden scrollbar. The visible scrollbar may have broken the overall fluidity and the UX.

3. Auto-closing landing page -

When anyone opens the website, the first thing they see is a vertically floating animated gif with a welcome message. There's also a function to skip to the main website. You can find the typewriter styled effect here.

4. Lowercase letters everywhere -

I don't know why I made that decision. I just wanted to be quirky in terms of the typography. I decided not to use any external font, because monospace was looking really good. When I started with the design I was using Nunito.

5. Large fonts size -

Previously I used a comparatively small font size which reduced the readability. So I decided to have bold and large font sizes for everything. Because of that, the text is retaining more space. Throughout the page, I have added extra line height and letter spacing for cleaner looks.

6. Click to view more information -

On the main page, you can see an icon [+] which will help you to expand the associated section. When you toggle the [+] icon it becomes [-] and vice a versa. Once you expand the other tab, the previously opened tab will close automatically. The reason behind this idea is to save some space and avoid excessive page scroll.

7. Satisfactory lighthouse score -

There's still a lot to improve in terms of performance.

Technical and other resources -

HTML5
CSS3
JQuery
FontAwesome - All the icons are SVG images.
Landing page image is from Google Images.
Profile picture illustration - by a friend.

So what's next?

Improve page animations. Sometimes page slows down while transitioning from landing page to the main page.
Remove JQuery. JQuery is a fantastic library, but I don't need it for a small website like this.
The transition between the day and night mode is not fluid. Add a small animation which should eliminate the rigid effect.
Replace the landing page's gif with better graphics (which should match with the profile avatar). Also, add a better favicon.
Add offline page with the help of Service Worker API.
HTTPS? Maybe...
Custom email address? Maybe...
Blog page, if I need one.
Bug fixes and enhancements suggested by others.
And many more things...

Inspirations, credits and special thanks to -

1. The Community -

The wonderful community of developers who inspired me to create my own website.

Building a Kickass Portfolio

Ali Spittel ・ Aug 2 '18

#portfolio #webdev #career #beginners

I Created My Portfolio with React and Some Magic 🎉

Dinesh Pandiyan ・ Apr 1 '18

#css #react #javascript #webdev

My New Kickass Portfolio Website

Michael Hoffmann ・ Sep 2 '18

#showdev #portfolio #webdev #career

Also, many more searches like this and this.

2. Dinesh Pandiyan - @flexdinesh, website -

I saw his website, and practically stole his idea of the raining background effect. It is so subtle and beautiful. Thank you, Dinesh.

3. Ali Spittel - @aspittel -

I asked her multiple questions, at multiple times while designing the website. Her guidance and opinions have been beneficial. Thank you so much, Ali.

4. Karishma Joshi - @karishmajoshi4 -

She's the genius behind the beautiful illustration you saw on my website.

My website could never have been possible without your support. Kudos!

Which mode do you like the most... Day or Night?

Explain JavaScript Promises like I am five.

Chinmay Joshi — Thu, 20 Sep 2018 03:26:35 +0000

I am starting to hate JavaScript. Before I blow my head with a gun, someone, please tell me how to work with JavaScript Promises.

Code management with Git and Github

Chinmay Joshi — Thu, 16 Aug 2018 14:10:24 +0000

Git is the most powerful version control system coded in the history of humankind. The super-rich feature set of Git makes the code management straightforward.

So today, let's discuss how we can follow a simple structure to manage our codebase.

Initiate -

When we kick-off a new project, we create a repository on Github. Followed by setting up or creating a README.md file. Now, it can be a public or a private project.

Collaborators and accessibility -

After that, we invite our collaborators to collaborate. Always setup access rights to the collaborators. For example, not everyone can merge pull requests. Only the code maintainers or core team members can manage the merging part.

Forks -

Every collaborator gets their own cloned repository so they can work independently. When you fork a repository, the primary repository becomes the upstream, and the cloned repository becomes the origin. We push our code to origin/branch-name and then it's merged into the upstream/develop. I like to keep my primary repository clean; therefore I suggest a fork based approach for development.

Most commonly, forks are used to either propose changes to the projects or to use someone else's plan as a starting point for your idea.

Branching -

So, when a collaborator wants to work on something new, they create a new branch depending on the type of the work they will be doing. So that, they can work on their features or bugs independently without troubling the other collaborators.
When you create a new repository on Github, you get a master branch, by default. Usually, all the developers or maintainers create a new branch from master, names develop.

develop should be the primary branch for merging your features, bugs and enhancements.

master - is a branch for production deployments.
develop - is a branch where we merge the code from different collaborators.
staging - is a branch in which we merge and test our code before going to production-level. Once we test all the functionality and the deployment cycle, we push/merge the staging code into master.
branch with unfinished work - When any collaborator leaves the organisation with incomplete code, or if he/she wants to transfer his/her ownership to someone else, it's a good thing to create a new branch on parent repository with his name. So the other collaborator can pull his/her code from there. Branch name can be something like this, collaborators_name/feature/feature_name.

It's a good practice to have (only) these branches on the primary repository. So it stays clean.
On your fork, you can create a branch based on the type of work you are doing. We can follow a simple technique to identify branches in a better way,

For a feature, feature/new-editor.
For a bug, bug/time-zone-fix.
If you have an open issue for this then, issue/:issue_number/issue-description.
Any enhancement, enhancement/background-color-update.

Very simple, isn't it? These are the industry standards or common practice that developers around the globe follow.

Pull requests -

Once the work is done we create a pull request from our branch to the upstream/develop. Now, it's a good thing to have different things set up on your pull request.

Reviewers - Reviewers are those people who are going to review your pull request. You can request more than one review to the pull request.
Assignee - Assignee is someone who is currently working on the pull request. There can be more than one assignee.
Description - explain what is the pull request about. You can add issue reference number to the description.
Labels - Labels are the best way to add identification to the pull request. Github has already given important labels. Such as - bug, enhancement, feature, wontfix, help wanted. So that other collaborators can identify the pull request without even opening.
Milestones - By adding milestones, you can track and filter your pull requests. You can find a detailed description over here.

Before merging the pull request, at least have two code review rounds with your peers. Usually, I like to apply different labels such as waiting for peer review, waiting for merge review, changes suggested, help wanted, ready for deployment to track the status of the pull request.
Other than that, I like to add different labels to know the type of the pull request. Like, feature, bugfix, enhancement.
You can create multiple labels to make your pull requests more identifiable according to your process.
The Github already predefines some of the labels.

Issues -

This is a very good place to keep track of your bugs and enhancements. You can integrate bug trackers to auto-create issues. Issues are shared between the collaborators where they can have a discussion about the solution.
There’s an assignees option, where you can tag different collaborators.

Releases -

Whenever you merge any pull request from staging to master, it's a release. Essentially it's a good thing if you can track your releases. Every time we merge code to the master, we increment the counter by one. Now, it's easy to track your versions. You can read more about Semantic Versioning here.

The simple explanation for generating a version number is, MAJOR.MINOR.PATCH

MAJOR - significant releases and features.
MINOR - When you improve existing functionality, improve code quality.
PATCH - for minor changes, bug fixes.

This is how you can draft releases with Github. It's simple and useful!

Real world example is Bootstrap -

Before merging the pull request, you can have different tools to make your code robust. Like,

Run test cases on a cloud.
Run linter to fix code quality.

Well, that's it! I have documentation for all the stuff that I mentioned. If you want it, write your email in the comment section below. I would be happy to share it with you.

Minimum Viable Product Rollout with ReactJS and Serverless Architecture

Chinmay Joshi — Thu, 12 Jul 2018 12:28:37 +0000

Recently, I joined a new organisation, Supahands!
As my first assignment, I was supposed to assess a few front-end frameworks for one of our products. It was a challenging task for me and I learned a lot through the process.

Story - For our new product, we had four frameworks in our mind. React / Vue / Angular / Ember.
After a few days of evaluation, we came to a conclusion that ReactJS is a perfect fit.

The product's goal was pretty simple to achieve. It was a simple CRUD operations app, with a few more service-calls to retrieve some data.
We already had a running product with Ruby On Rails + PostgreSQL stack.
After inspecting our objectives, we realised that we needed to adapt to better technologies and architecture.

We were trying to achieve the following things:

Move our business logic to independent services (AWS Lambda).
Introduce new UI design and Template System for the application.
Write a Client-Side application in React.
Restructure our current database and migrate to DynamoDB.
Automate CI processes and current deployment strategies with the help of AWS CloudFormation. Our business logic is tightly-coupled with the deployment stack.

And why were we doing this?

To minimize the cost.
To re-use services in other products.
To have a Client-Side single-page application.
To maintain and share a common database with multiple applications.

And... did we achieve our targets? YES!

What did I do in the process?

I participated in the app's UI design process. I converted those designs into JSX templates with the help of Bootstrap.
I successfully wrote code with React for our Client-Side application (from scratch).
I deployed our React app to AWS.
Adapted myself to Serverless architecture. And, still learning...
I wrote backend services in Python 3.6 for AWS Lambda.
I designed a better structure of the database in AWS DynamoDB.

Why was it challenging?

I was working with React and AWS for the first time.
I had no idea how Serverless technologies work.
I have never worked on a front-end framework on my own from scratch to go-live.

So, what's next?

Improve the app's code base.
Add test cases for front-end app.
Add Redux for state management.
Make the app mobile-friendly.

Special thanks to dev.to and the community. I have referred a lot of threads for React and Serverless development!

What can a developer do to enhance User Experience?

Chinmay Joshi — Thu, 14 Dec 2017 13:17:08 +0000

User Experience (UX) refers to a person's emotions and attitudes about using a particular product, system or service. It includes the practical, experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership. - Wikipedia

Essentially, user experience development is designing an interface with keeping user's perspective in mind. But, people often confuse UI with UX. UI is what makes the system look beautiful, and UX is what makes the system useful. In a typical system, UX drives the UI, and it is the science behind the visuals. It also keeps the user connected with the system.

Before we discuss how to improve UX, let's look at the process of developing the UX for a system. Usually, it has the following flow -

Identify system objectives and user requirements - Before starting any development, a developer must understand critical goals and what the system aims to achieve. Along with that, clarity of end-user needs is also essential.
Define system constraints - After identifying system objectives and requirements one must apply various parameters such as time, budget, team, accessibility and other factors that affect the system to define the scope of the system. We must keep in mind that, this is an iterative process so we may not achieve success in the first few tries. We must also make sure that these constraints are well documented.
Build user flows - Now that we have defined and documented the scope, we need to decide how the end-user is going to interact with the system. A simple way to do that is to build user flows. These user-flows should consider as many use-cases as possible.The simplest way to define user-flows is by using flow diagrams.
System interface and information design - By creating user flow diagrams, we have created different patterns for our end users regarding usability. In short, we have defined the intended behavior of our end-user. Now, it's time to bring structure to our system regarding looks. We should decide the placements of elements on the system interface in such a way it requires the least amount of effort to access it. This is ultimately going to help us validate our user flows. We can further cement our validation by creating multiple wireframes and mockups.
Build graphic or visual design - Creating graphical or visual design is a process where UI and UX development work together. This is the step where we will add different flavors to make it relishing. When I say flavor I mean, color palettes, themes, templates, images, typefaces, icons, typographical elements, interactive patterns and many more things. Each and every flavor is going to play a vital role in beautifying the system interface. This is where the system will start looking more alive.

Till now everything was pretty much pedantic, let's make it more exciting and dive into the meaty parts of improving user experience!

Wireframe, mockups and design libraries/frameworks - We have already discussed the advantages of creating wireframes and mockups. We can use wireframe.cc, mockflows, moqup.com for creating wireframes. There are many design frameworks available in the market like Bootstrap. Using such a framework is going to provide significant support to create a template system. Choosing the right and customizable framework is the key.
Right color combinations - Use eye-catching colors to enhance UX of your interfaces. Good designers use a few theories about colors patterns to make things look good. They usually a follow 60-30-10% color-ratio, which gives balance to the color scheme. Where 60% is the dominant color, 30% is the secondary color, and 10% is for accent color. Check this link, for further details. Color combinations should depend on for how long user is going to use the system. For example, if your user is going to use the system for all day long, then it’s a good thing to have light background and dark text. For visualizing and using right color combinations check out different websites like colors.adobe, coolors, colorcombos.
Prioritize data - If you have a significant amount of data to be displayed on the system interface, then prioritize your system requests. You don't want lower priority data to be presented first. It might not affect the users with high-speed internet, but what about those with a slower connectivity? A simple example can be seen on social networking sites like Facebook. If you notice, Facebook always loads the posts/feeds first as it’s their primary information. Other data like Birthdays, Events and Ads are displayed after the posts are rendered.
Build a guidance system and documentation - It’s good to have system-related information on the go. Create links for system documentation to explain more about various features. Add FAQs and have a feedback system. Add tooltips and guideline tours wherever needed. Adding social media links can benefit you in multiple ways. You might want to take different surveys from end users, by keeping them interactive, they’ll make end user feel being a part of the system.
Discussions or team communication - Have conversations with your UX development team about design patterns, implementation strategies, use cases and user flow. Team discussions often bring new ideas to the table and may also spot a few use-cases missed during the planning.

So, whatever we have discussed right now are baby steps that may help you in the long run. And It’s worth to bring these vital elements to the system development process. It is going to save a lot of time, effort and possibly, even money. So now that we’ve discussed a few Dos, it’s time to look at a few Don’ts. These are the typical mistakes which to avoid while developing a system interface.

Avoid dark background with light colored text. Imagine yourself, reading a book, with black pages and white text. That is going to be really scary for your eyes.
Try to avoid page reloads.
Also, avoid requesting too much information. Isn't that boring to fill out lengthy forms while we sign up? It irritates me when the system keeps asking me more birthday, addresses, etc. This might be valuable information, but you can take that later too.
Earlier I mentioned about the importance of user feedback for your app, but we should also ensure that we don’t overuse reviews. For, e.g., asking input in first few days of his/her usage makes no sense. Define your medium for asking reviews, it can be in-app forms or email surveys. Google forms can be a good option. Often, asking reviews from regular users and power users we can get some valuable feedback.
Avoid too many notifications and ads which are blocking the page content.
Avoid grainy and low-quality images.
Avoid too much scrolling unless necessary - If your page content is vast then instead of a scroll, add navigation buttons on the design or implement special navigation panel for that.
Avoid displaying repetitive information on the same page. Use precise, short and simple text. Avoid negative statements from your content. Ex, Instead of ‘user is unavailable today,’ you can say ‘user is on leave today.’ Use the services of a copy-writer or online grammar checking tools, like Grammarly, to keep your content grammatically clean.

So these are the few things which we experienced while working on different products at work. We noticed that by adopting these points made a positive impact on the overall user experience of our products, But this is by no means an exhaustive list, and I’d be glad to know more opinions from the community.
What else do you think can a developer do to enhance a User Experience? Leave a comment!

Reference links and further readings -

UX Smells - link
Better Stakeholder Interviews - link
Four Reasons Users Uninstall Apps - link
Pattern Libraries - link
How to teach yourself UX design link
User onboarding tools - link

Special thanks to, Shaunak. For helping me write this blog.