Understanding UX Basics

I don’t have much knowledge about extremes of UX things, but whatever I could understand in my last one year, I am jotting it down, so that It can be helpful for other too who wants to try hands in UX or are already doing UX but not in right way. In last few years UX has started playing very important role in SDLC. What is UX? If we look at it from 100 ft above the ground, we will find that UX is a small process to create better design, which is user friendly. As its got a self explanatory name, it defines experience of the users, which determine whether or not they enjoyed their experience.

Before we jump on any final steps, lets find out what are the basics for UX and how you can achieve a better UX. Effective user experience starts with a good understanding of your users. Not only do you want to know who they are, but you want to dive deeper into understanding their motivations, mentality, and behaviour. This deep insight into your users will help you keep your product focused on delivering a great experience. But how do we know what our users really want? and thats the reason behind my writeup.

Let’s look at all the possible steps a UXer might take in defining the UX of a product. These steps create the ideal process. These steps aren’t always possible to complete in the real world, but we need to cover all of them so that you’re aware when you can leave out certain steps and why. Sometimes you don’t necessarily leave out a step, but it is melded into another step, or replaced using a combination of experience, knowledge, and intuition.


It is the very first step to design a better UX. In this process you ask questions to gather requirements (all types of, business, technical, targeted users, design etc.), having said that, its not necessary that you get answered all at the same time or in early stages, but that matters less than asking questions.


Its one small segment of the requirement gathering process. Its as important as you do anything else in the process. understanding your users or targeted users is equally important, for an example, if you are creating a banking app, you cant think of experience of a game app, as targeted users for both apps are different. Usually we ask, who is this for? demographics, likes/dislikes, occupation etc. What is the problem statement we are solving for users? etc.


Once user analysis is done the second step is task analysis. In this we analyse, What is the main action/task user need to perform? This essentially means that you we need to find out what is the main problem which is your application solving, that is the main task of your application. Once you have identified the task, you need to optimise or design the UX according to that task for the user base you have analysed in earlier task. Sometimes we may need to find out further levels of tasks, as your application is not only for one specific task, and user may want more functionality, which is possibly you have it too. Scope out all of these to know the breadth of what you’re designing toward.

Functionality distribution

Once you are done with your user base and tasks (primary/secondary/tertiary) you need to sort out the place or allocation of your tasks/functionality, I call it functionality distribution. It occurs on several levels, like, what will be done on back-end and what will be on front-end?, how the user experience will be? will you need ajax calls for better user experience or not? what will be SEO friendly experience? etc. The answers to these questions can dramatically influence the efficiency and usability of your product.


I liked this line – “Sketch. A lot. It’s quick. It’s cheap. It’s effective. ” Its so true and useful. Sometime you can take this line as a base for all UX. It gets lots of ideas from your head to paper. Best idea is involve team members in sketching exercises, be it UI dev, Backend Dev, BA, QA or any role, if time permits, may be some sort of small brain storming sessions, believe me that helps a lot to get great ideas from minds which are hidden and eliminates the bad ones, after all its a team effort which makes any product success and team involvement also helps them to keep them in same loop and thinking. If time doesn’t permit this team activity, try to come up with a bunch of ideas as sketches and show it to team with a small discussion session, explain them and ask feedback. This helps a lot you can imagine.


Once you are ready with your final (or some sort of good shaped) sketches, lets do first level of wireframes. Its not necessarily be on digital media, you can create sketches in a way that it start explaining user journeys or some sort of information architecture.


A prototype is a clickable version of your wireframes/sketches which can explain a basic user journey or task or functionality of your app. There are lots of different prototypes you can do. It can be clickable pdfs, or clickable images stacked in some web page, some full functional HTML/CSS/JS based layout etc. It really depends on what you need for your project as to how far you go with it. You can use Balsamiq, Axure, Invision, Fluid UIBootstrapOmnigraffle etc. Find out which tool suits best for your requirements and can serve the purpose of quick prototyping, but make sure that they are able to communicate your design/workflow properly.

Usability Testing

This process can take place anywhere and whenever required, ideally if there is some basic working clickable prototype is available, do a first round of user testing on it to get early feedback and loophole which you may have missed so far. The time for this process in whole timeline may vary but that totally depends on what you need and when. If you go in Agile UX or Lean UX way, its better to do it earlier and improve on it in every step. I personally think that we can do this even we have sketches only, but having the same user base for testing such early stage is also a pain, as user may not understand from your sketches what is expected and what will happen. But you can still get an early feedback from that too. This is to understand that whatever you are trying to create is even useful or usable for users, which may vary according to its time, and prototype fidelity.

High-fidelity Visual Designs

Its time to take all the experience from user testing, sketching, wire-framing into the real designs, so called high fidelity wireframes/designs. In this phase you can select colours, layouts etc. Most of the cases we’ve seen that after this process UX designers create all designs and pass it to further with keep fingers crossed, but Agile UX/Lean UX are not different than team, in that we work very closely with team so we don’t need to cross our fingers and still need to keep an eye on how things are moving or if there are any obstacles in the design we have developed, or is the design still need to factored out according to the data we have in application etc.


As I mentioned in early stage that in Lean UX your work is not done once you submit your designs to development, you should be working with developers. This may not be quite as collaborative but there are often issues that arise during this stage in which you’ll need to adjust the UX. This also helps you to gain an understanding of the technical limitations for future projects. Your developers will be much happier for you to gain this knowledge rather than designing impossible solutions. It helps cross functional team expertise also, you exchange information across functional areas, which is always better as it is always about information, isn’t it?


Finally, these are only processes which a UX person should follow, but its not necessary that you will find all of them to be followed religiously, but these are guide lines which helps to make a UX better, as I mention it earlier too, “UX is everything. Everything is UX“. These steps create the ideal process. These steps aren’t always possible to complete in the real world, but we need to cover all of them so that you’re aware when you can leave out certain steps and why. Defining UX is not a straight forward process that you follow, it always changes project-to-project and according to the  requirements, project conditions etc. Sometimes you don’t necessarily leave out a step, but it is melded into another step, or replaced using a combination of experience, knowledge, and intuition. This is a basic workflow of any UX person, who works in a Lean UX way.


0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *