Published on | Prototyping: From UX to Front End — Medium Jingyi Lai The only walker on the road — Photo by Jeremy Cai on Unsplash

A Guide for Those New to the Game

For designers who don’t have a lot of practical experience in the actual design industry , especially the fresh graduates without enough design internships (like me 😅) and the brave adventurers just changed their paths from another industry, the FIRST design job is always a hurdle.

Some of them can win an offer in a company with a relative mature design team, but in most cases, they will end up becoming the design team of one in a startup.

Why?

The reason is simple: The companies just entered the design game will meet those who just jumped into the design industry.

Design is becoming much more important than ever in the business world and people are getting to see the value of design and the importance of user experience, which makes every company, big or small, wants a designer. However, not all the companies are aware of the real value of design. In other words, some of them will have lower budget and expectation for the incoming designer, which stops the experienced ones going but attracts the fresh ones because as a new player, we simply appreciate any job we can get.

Some people may argue this is not a common case, but there are multiple similar examples happening around me over and over again, and this is why I would like to share my experience with you as the design team of ONE for 15 months.

Is It A Bad Thing to Be A Team of One?

NO.

Absolutely not.

I would rather say, it is a big challenge but an precious opportunity to grow. It is a challenge because it is highly possible that our company is as fresh as ourselves, it might not even have a product, not to say a design culture. Everything about design is going to on us, which means there is no design supervisor to turn to, no teammates to discuss with, no mature design guideline to refer, no product roadmap to follow…but it also means we can control the entire look and feel of the product! We are give the product the live and grow fast.

But there are always obstacles .

As the fresh new ones, we might have several side projects that we prepared for the interview, maybe some group projects as well. But they are not actual experience. We may wonder what to start with, when to start, and how to start. Maybe we wanted to start by doing some user research, but was told that the company didn’t have target user yet; maybe we wanted to look at our competitors, but not sure who they are; maybe we wanted to follow the research-ideation-wireframe-interaction-visual process but was told that a pixel-perfect mockup was required by next week to present to investors…

There will be a lot of these happenings. We will be in a really irregular and unstable design process. It is hard to implement the classic design-thinking process in an early-stage organization.

As the sole designer in nanopay for 15 months, I have experienced all mentioned above. Now we are walking into a more steady stage after the chaos, and I would like to share some tips for the design team of ONE.

1. Be Confident

I know, when we first joined, that feeling. Full of uncertainty and unknown, not to mention the anxiety of being elevated by people around us in a brand new environment.

But remember, we got hired, which means we are qualified and approved as a designer here. And we are the only designer, which means we are the most knowledgeable person in design here. So think carefully, and make each decision firmly.

2. Understand the Company’s Mission

Here I’m not talking about the preparation we do for the interview. After we got hired, we are part of the company, so it is necessary to understand the company’s goal, the building product and the core technology. Maybe there is not a product yet, but there should be a pain point that they discovered or a technology that deserve digging in.

New employees in startups might not have a comprehensive training period, instead, we have to jump into the mud and keep hands dirty right away as we don’t want to fail the probation😢. This is the reality.

So if we got a training, it is nice. But if not, ask questions. Our manager will be the best resources for knowing what the company is doing and why, so we can get some directions from there.

3. Compromise When We Have To

When I first joined, the company was busy presenting our product to clients all over the world. The CEO can be in Toronto today but Europe tomorrow, and New York the day after. We were craving for every possible opportunity.

In that case, developing a fully functional product was not wise nor possible. With tight deadline, we always had to finish a product with limited functions in a short time with no time for user research or testing, not to say irritation. We’ve had 3 different formal presentations in Finovate last year, 201702, 201704, 201709, which were in different product direction looking for different market fits, not to mention small demos to clients separately .

My suggestion is to do what we need to do in those cases. It might not match exactly what we have learned at school, but it is the reality, we are gonna need to be flexible.

4. If Possible, Learn Some Code

Search on Google “should designer code”

There are lots of discussions and arguments online about whether designers should know how to code. Personally, if the designer only focus a specific area that has no direct connection to development, like prints design, package design, etc., it is ok to keep away from code. Otherwise, though it is not necessary to know how to code, at least understand how it works.

Especially as the design team of ONE.

We will be working closely with the development team, and usually a bigger team than our team of ONE, sometimes developers may not be able to understand our design rationale, sometimes they are not implementing as we imagined…We can hardly expect a large team will be able to understand us thoroughly, so it is always better to be able to speak their language.

I will give you a small example.

When I first started my career, I was working on redesigning a price-match website containing lots of product cards with information like product picture, product name and price. At first, my design has a gap of 30px between 2 cards, the front-end developer asked me whether it was OK to make the left margin of the first card 15px. Well, I didn’t understand what he meant, so I simply said, I need 30px between two cards, and there shouldn’t be any gap like 15px for the first one… So the sample website was a one without margin on the left…

LOL.That was because I didn’t understand the box-model of web development.

But now after I have put some efforts on HTML, CSS and really basic JavaScript, I’m able to put myself in the developer’s shoes when designing. There are some small things that we can do in design to make development easier, for example, keep consistent with the margin between divs, also offer a better visual experience and consistency. When I’m handing off to the developers, I’m able to explain my expectations with slight technical words-

The maximum width is 960px, when the screen is bigger than that, the content should be at the center.

and even sometimes some suggestions!

Use box-sizing with border-box, then we can include the border size in the box size!

It is always helpful to learn a little bit code, to understand how our design will be implemented, and better communicate with developers.

5. Communication and Communication

As a design team of ONE, everything will be on us.

We will get requirements from business teams, and hand off to developers, multiple changes back and forth, especially for technical constraints. We need to actively communicate with the teams ourselves.

If we have doubts on the requirements, ask why and understand their intentions and the good for users. If the product is not accordance to our design (believe me, this will happen many many times until we have a solid review system), we need to proactively go head and talk with developers, understand why they didn’t follow the design, maybe themselves didn’t think this is a good design, maybe because there are technical constraints, or maybe they simple didn’t notice this detail( from here, we can start thinking why we didn’t make it clear enough to developers, and we can start from there to revise our workflow).

6. Get Feedback from Everyone, and Learn

We may feel without other designers here, we can hardly get any feedback. But everyone in the company can provide feedback, and they are sometimes more valuable than the feedback from an actual designer, because non-designers have a not-biased mind and a fresh perspective to look at.

A good collaboration among teams will be continuous questions and answers here and there. Answer the teammates doubt, and this will bring new perspectives to the design. For example, at one time I delivered the design for the on-boarding process, but Sarah from the QA team asked me a few questions on the flow, which made me aware that a few screens was missing.

Also, there is a lot that we can learn from everyone though they are not designers. We can learn development-thinking from the development team, soft skills from the business team, how to better explain to clients what we are doing from the marketing team…The gains for a designer is always far more than just the pixels or micro-interactions.

P.S. Though we might be the only designer in the company, but there are so many designers out there. Reach out to them when we need to.

How I got started with networking: it helps me become a better designer though I used to hate it

7. Bring the Design Impact

Easier talk than done. I know, but it is us who are going to bring the impact of design to the rest of the company as the design team of ONE.

People might not see the value of design, might not understand what design-thinking is, might still take us as just someone to make things look nicer…So take actions, start with something small, gradually let people understand what we are actually doing and what we can bring to them.

I have tried a small experiment before, and it was well-received. You can try to do something like this, bigger or smaller, as you like, to start showing your true value as a designer.

In the PingPong Room: How I moderated a design exercise as the sole designer

If that is too far away, try doing the same thing, but in a hackathon. In those cases, there will be plenties of opportunities to convey the value of design to the rest of the team developing a small product.

Bring Your Impact: How I Applied User-Centred Design in a Hackathon

Some Last Practical Takeaways

Read this book — The User Experience Team of One

This great book covered the topic much more in detail and depth, alway explain lots of practical methods we can apply to the work right away

The User Experience Team of One

2. Start using tools like Zeplin or Invision Inspect

I used to manually add spec on the screens, which took forever and less accurate. These tools will show all the color and font details accurately and auto-generate CSS, which definitely accelerate hand off.

3. Always go back and look at current product before designing

This one looks obvious, but surprisingly, I always forgot it. After we hand off a design, changes still happen, which might result in the discrepancies between the current product and our screens on file. It is easy for us to jump in designing without the mind of current product.

4. Flow and prototyping are very important!!!!

It already happened to me several times that I forgot to design one or two screens in between, or didn’t think of the transitions between two screens (e.g. it is a loading state? or there will be some fade in animation?). Before I always expected the developers can handle that on my behalf, but now I noticed that as a product designer, we need to cover the all-round of the product.

No matter how small the new feature it is, start with the flow first, according to the flow, we can find the gaps we need to fill and we won’t miss a single screen. (Didn’t want to tell you that I had been asked multiple times what will happen if this ,what will happen if that….😭)

5. Pay attention to the UI states

Another easy to forget for me.

The ideal state, partial state, loading state, error state and empty state. If one missing, the flow is not smooth, perhaps the users will see something like Code dfauer23xxxxdfe3d f<dfdt>. dfdfer.dwoiiumnh.

I noticed it is a lot of work. YEAH. A LOT. The younger me thought UI design was only screen one by one, but the reality is FLOW always goes first. Multiple UI states correspond to different flows, and different user stories.

6. Keep the files managed

As the product grows, there will be more and more projects, some out-dated ones, some old ones, some new ones…Find a way to better manage the design file versions, and the screens. Sketch has some versions saved, but version control tool like Abstract can also be taken into consideration.

7. Consider component design and design system

Start thinking of building a component library and the design system once the product is relatively mature (e.g. had the first beta release).

The symbols, styles and libraries in Sketch is very helpful, carefully manage those and gradually start building the design system to unify the design language and accelerate development.

This also helps if more designers are joining, or one day we need to move on, so we won’t leave a messy plate, but, a carefully arranged and well seasoned dish.

8. Document the design rationale and changes

One day we may forget why we made such a decision, and things are worse when development team is questioning a specific decision( can happen, as design is usually one sprint ahead of development for the same project) but we forgot.

When we reached a consensus with the business team on some changes, always document them somewhere so we always have those prepared to answer questions, also for the future reference.

I normally use Google docs, but recently noticed Dropbox Paper is also a good choice with nice and clean interface.

Well, the above is what I can think of can help the team of ONE survive.

I’m still learning and fighting as a design team of ONE, the same as many of you there. We promise, we will work hard and will grow strong, and one day we will graduate from the team of ONE.

Jingyi is a product designer. Welcome to connect me via Dribbble, Linkedin, and Twitter.

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

Survival Guide for the Design Team of ONE was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Survival Guide for the Design Team of ONE

Cool stuff, every week

More Articles