11 rules I live by as a UX-team-of-one in an early-stage startup
What I learned in my “first 90 days”
My “first 90-days” at Empowerly, an early-stage startup, was spent speed-fixing an utterly broken web app so that our users can successfully access our basic revenue-generating service features to complete their tasks. Now that the product is patched up, we saw our user engagement up by four-fold — and can at least for a brief moment let out a sigh of relief. Of course, this is just the beginning of a very, very long journey.
I decided to reflect on my experience of this first operation. Here’s my survival guide for anyone else who might be working as a lone-wolf designer with a handful of engineers and 0 product managers:
1- Prioritize all that is needed for the red-route
For a user to obtain minimum value out of our product, they have to be able to access your product and complete at least one important task. This is UX design 101. Make sure the product is ready to guide your user through the experience from sign-up to sign-out.
If you are soft-opening a community center just for a theatre show, you need to make sure that the entrance is paved, the lobby and waiting areas are done, the elevators and stairways are built, the toilets are accessible, and of course, the theatre itself is ready. The swimming pool? Not so much.
When you have a million different possible problems to fix and features to develop and are the only one on the job, always ask yourself what is necessary right now and what can wait. Writing out your user stories is super important.
2- Seek front-end solutions first
Many usability issues can be resolved by writing better UX copies and putting buttons in the right places. Since I had to be mindful of the limited engineering capacity (we had one full-stack engineer capable of backend work), I prioritized solutions that did not require creating new API calls. (Of course, this rule is only relevant to certain specific, time-sensitive contexts.)
3- Usable is better than perfect
Under time-sensitive conditions, it is okay to let go of the expectations of achieving 120% on every single one of NNG’s ten heuristic principles, as long as you commit to constant reiteration over the long run.
4- Don’t neglect your teammates
Operations, sales, and community managers hold valuable first-hand insights of our users, customers, and other business stakeholders. Harness their knowledge first! As the only designer on the team, I avoided working in a silo by running internal workshops to learn what they know about our customers/users, align on the company’s missions and goals, set feature development priorities, expectations, and product release benchmarks.
5- Use workshops to structure complex dialogues
Relying on sticky notes might look like a silicon valley cliché, but I find them to be an extraordinarily effective way to harness everyone’s thoughts while timeboxing the process. I thank them for their capacity to prevent 8-hour-long rabbit-hole discussions.
6- Don’t neglect the user
As a UX designer, half the job is about advocating for the user. Of course — running interviews does not feel like a priority when you have a lot of little bits and pieces to design under time-pressure. And of course, it is difficult to test/research every single feature or element. As a rule of thumb, the more complex a design task/feature, the more user research and usability testing goes into it, regardless of how little time I have. We all know that it is also our job as UX/product designers to help others realize the importance of research. Fortunately, our engineers don’t want to waste time building things no one will use, so our entire company is pretty supportive of user research.
7- Designing the UX of team collaboration
Optimizing for teamwork efficiency was crucial to delivering the product on time. To achieve this, I treated workflow design as a UX experiment in itself and tested different methods of making our engineers’ lives easier (it’s an ongoing process). Things that worked: implementing two-week sprint cycles, using Trello board to delegate work based on capacities, using Airtable for engineering oversight, and using Monday.com to manage our product roadmap.
8- Provide enough documentation
In the spirit of collaboration, don’t forget to produce enough documentation for handoffs. This means providing more than design specs but also diagrams such as user flows, wire flows, or handwritten(typed) notes. Take care of the edge-cases. Sure, in a startup environment, scrappiness is somewhat expected, but I’ve also learned that no amount of clarity is too much.
9- Benchmark before product release
In the fast-and-furious work environment, it is easy to forget assessing the quality of the product you put out in the world. To prevent this from happening, I implemented a method of gatekeeping — before a release, our colleagues all got into a room and attempted to complete a said task. They then graded the product on a predetermined rubric (written by our executives) and jotted down notes on what needed to be improved or fixed before launch. This way, we are able to catch problems and also have our entire non-technical team to become familiar with the latest product release.
10- Don’t forget to document and archive your work
Regularly take screenshots of the product in development for your portfolio! I keep forgetting this. I don’t have a selfies mentality. However, maintaining a record for your portfolio/case studies is necessary, and once a product gets updated, it’s hard to access the older views, if at all possible. I do force myself to write case studies regardless of whether I am job seeking because it helps me reflect on what I’m doing and ensure I’m not skipping steps.
11- Don’t wait for instructions
This point is self-explanatory. You’re the only designer in the entire company. Who can you expect to give you directions? Be the person to take the extra step and try to over-deliver.
As the only designer on the team, it becomes natural to assume some of the responsibilities of a product manager given the many overlaps in job nature. I don’t find it to be a burden, but rather relish the opportunity. How often would one get to be a creator while at the same time setting long-term product goals? The constant planning and prioritization is no less a creative journey in itself.
Of course, there’s always a small doubt in my mind that I’m not doing something right and I lack guidance on the job. But it’s always important to remember that just because no one is teaching you doesn’t mean you are not learning. If you have feedback on any of the above points, I welcome your comments below. :D
For related case study, click here.