Published on | Prototyping: From UX to Front End — Medium Kshipra Sharma Image source: unsplash.com

A primer for anyone new here.

After two years of hardcore Design school, I finally stepped into the industry. I thought I knew how it goes, after all, I had been a good student all my life. But no amount of straight A’s can prepare you for what lies ahead in the industry, though it may definitely help to know your theory inside out. I made a list of things I learnt, and I thought it could be a nice hand-me-down to an anxious fresher in the industry.

Iterate quickly, build for the Minimal Viable Product (MVP), think to scale.
When I joined the product company I am working with, I was apprehensive that would I be out of things to do, what after a product is launched? Do I sit there, and browse the internet till a quick fix comes by? The interview panel had smiled at my naive question. This is something we’re not taught in college, we usually live with one idea and present it to the jury and then move on to the next project there. Cut the chase, today everyone in our team is handling at least three projects: an upcoming venture, something you’re working on right now, and evaluating something thats running in the market. Our hands are always full. This is because unlike college, great products are not built overnight, but in a lot of versions and releases. Visions and scenarios of each product changes by the time we reach our first vision and its time to build again, and scale up for new things. The work is never over, you will always find something to improve upon.
Designers are facilitators of discussions between stakeholders for usability, feasibility and vision.
As much as we like to work in isolation with just designers, our job will be to coordinate between Project Managers, Devs, Clients, Users, and every other stakeholder of our product. And no design would be complete without all these being on the same page/table. Hence, we’ll be doing a lot of conversations, some difficult ones and some exciting ones. Without these conversations, most product designs will only dwarf at prototype level, which is something you don’t want to see.
Be a nice person.
It is as awkward for the person infront of you to tell you what they need, as for you to ask it. Its important for anyone in front of you to be comfortable, and for you to seem approachable and not condescending to their pain points. Being a nice person doesn’t mean you need to shower everyone around you with rewards and chocolates, it just means you need to be empathetic with everyone and their journeys.
Be open to learning and criticism.
You can’t please everyone, but you can certainly achieve a benchmark. A lot of design criticism will happen inside the team and outside. While not everyone will tell you everything useful, value their intention and filter out honest feedback, which you could do by listing your own pros and cons first, and confirming it with others. Feedback can feel harsh at times, but its nothing personal, so don’t feel disheartened.
Thought Leadership > Computer Skillsets.
While computer skills can give you an immense head start to saving your time, and upgrade your quality of work to a huge extent, thought leadership and management skills will take you to greater places. Reason being simple, skillsets can be bought at a much lower cost than thought leadership. New ideas and deeper understanding isn’t too easy to find; in fact it is probably your biggest skillset.
You will wear many hats.
Unless you’re working in a ‘very’ big company like Google/ Microsoft, more often than not you will be wearing all the hats on the design table. This will mean that even if your core competency is interaction design, you will also be working on visuals. Often as you grow with a product from MVP level to version 2 or 3, you will need to learn which design research methods work for your product. You will conduct usability studies yourself, you will be your own data scientist, you may even code/animate, depending on your role. Be flexible.
Work on paper.
A lot of your work will happen on paper a lot of your ideas will get killed on paper too. When I joined the industry, I felt too conscious of working on paper too long, when all other teams tapped away their laptop keys (open office?). I like using stationary and scrawl notes and afterthoughts, all over the place. I think I was also too intimidated by showing these rough scribbles to people around me (because they weren’t as beautiful as they were expected out of a designer). I started skipping this practice, when I wanted to look like I’m doing ‘actual’ work, and often jumped to digitising my flow as soon as possible. BAD IDEA. While working the solution in your head, you are likely to think in chunks, on paper is when you put those pieces together (quick and dirty), skipping this step is likely to waste a lot of time as you get warped into polishing details than putting those chunks together.
Document everything.
A lot things will be said over conversation or an afterthoughts to meetings. You may or may not remember everything, and so to those around you. So often the product is made, and no one remembers why exactly certain decisions were made . Onboarding new people without documentation also becomes a huge task, as no one knows who should they talk to, for what detail. There might be good ideas floating, which could work for your v2’s, but no one remembers. Hence, document everything, take pictures, send m.o.m’s, be as quick about this as all this information is as ephemeral as your memory about what you ate yesterday for breakfast.
Read a lot, bring imagination and foresight to the table.
You don’t need to just look at design books for inspiration, honestly design books can be repetitive and full of jargon after a while. But if you look up allied fields for inspiration, you will never run out. Read science fiction for example, or economic theory or history or psychology. You can never run out of ideas if you’re always fascinated with the vast universe of knowledge around you.
There are multiple sources of truth.
While dealing with multiple stakeholders, you will find multiple sources of truth. But it is important to find them all and accommodate them all. These are the use cases which your Business Requirement Document (BRD) does not cover, these are the use cases that come from visiting the ground, and observing users. While often your BRD may seem very straightforward, I would always suggest you that no matter how ruthless your timeline is, if you’re not able to accommodate a full blown research, you must always take 15 minutes to talk to an actual user about their process and their expectations from a product.
Design is in the details. Design is in the big picture.
While big pictures are important for designers, to make room for scaling up, a lot of experience design is in the details of interaction and visuals. Its a kind of detail design school never taught us too well, because we usually talked about big pictures. But in order to make pretty big pictures, industry requires you to develop that eye for detail, even if you’re not building those details. Consistency across these details, makes the picture glitch-free.
Enterprise UX is a different ball game. While most of the internet is abuzz with fancy interfaces full of colours, a majority of tech industry is involved in building products which aren’t necessarily customer facing and may involve simplifying extremely complex processes to the larger audience. This side of UX isn’t much talked about, this isn’t always about direct conversions and user delight, and may be referred to ‘boring’ by most college students. However, no matter how complex the problem, it is our job to simplify it.

Originally these pointers were a part of an interactive session conducted with my juniors in B.Des, at IIT Guwahati( November 2017). The response there was good, so I thought I’ll add more to my list from there on. If you would like me to add anymore insights to the list, hit me up with the comments section below or on the notes.

A huge shoutout to Avisek Bhattacharya , Anulal VS, Asif Zaidi at @ Delhivery Design for helping me wade through the industry. ☺

This article has also been published at UX Collective and Delhivery Design blog.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Reflecting on my first year in UX industry was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reflecting on my first year in UX industry

Cool stuff, every week

More Articles