{"id":18713,"date":"2019-12-16T16:00:45","date_gmt":"2019-12-16T16:00:45","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=18713"},"modified":"2020-09-03T12:45:41","modified_gmt":"2020-09-03T11:45:41","slug":"important-rules-ux-team-one","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/important-rules-ux-team-one\/","title":{"rendered":"Important Rules for a UX Team of One"},"content":{"rendered":"

My \u201cfirst 90-days\u201d 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 \u2014 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.<\/p>\n

\"\"<\/a>Before<\/p>\n

\"\"<\/a>After<\/p>\n

I decided to reflect on my experience of this first operation. Here\u2019s my survival guide for anyone else who might be working as a lone-wolf designer with a handful of engineers and 0 product managers:<\/p>\n

1. Prioritize all that is needed for the red-route<\/h2>\n

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.<\/p>\n

\"\"<\/a><\/p>\n

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.<\/p>\n

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.<\/p>\n

\"\"<\/a><\/p>\n

2. Seek front-end solutions first<\/h2>\n

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.)<\/p>\n

3. Usable is better than perfect<\/h2>\n

Under time-sensitive conditions, it is okay to let go of the expectations of achieving 120% on every single one of NNG\u2019s ten heuristic principles, as long as you commit to constant reiteration over the long run.<\/p>\n

4. Don\u2019t neglect your teammates<\/h2>\n

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\u2019s missions and goals, set feature development priorities, expectations, and product release benchmarks.<\/p>\n

\"\"<\/a>Team workshop<\/p>\n

5. Use workshops to structure complex dialogues<\/h2>\n

Relying on sticky notes might look like a silicon valley clich\u00e9, but I find them to be an extraordinarily effective way to harness everyone\u2019s thoughts while time boxing the process. I thank them for their capacity to prevent 8-hour-long rabbit-hole discussions.<\/p>\n

\"\"<\/a><\/p>\n

6. Don\u2019t neglect the user<\/h2>\n

As a UX designer, half the job is about advocating for the user. Of course \u2014 running interviews does not feel like a priority when you have a lot <\/em>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\u2019t want to waste time building things no one will use, so our entire company is pretty supportive of user research.<\/p>\n

\"\"<\/a><\/p>\n

<\/div>
<\/svg><\/div>

\"As a rule of thumb, the more complex a design task\/feature, the more user research and usability testing goes into it, regardless of time.\"<\/p><\/span><\/blockquote>\n

7. Designing the UX of team collaboration<\/a><\/h2>\n

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\u2019 lives easier (it\u2019s 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"By treating team workflow as a UX experiment allowed us to try and test different methods to make people's lives easier.\"<\/p><\/span><\/blockquote>\n

\"\"<\/a><\/p>\n

8. Provide enough documentation<\/h2>\n

In the spirit of collaboration, don\u2019t forget to produce enough documentation for handoffs<\/a>. 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\u2019ve also learned that no amount of clarity is too much.<\/p>\n

\"\"<\/a><\/p>\n

9. Benchmark before product release<\/h2>\n

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 \u2014 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.<\/p>\n

\"\"<\/a><\/p>\n

10. Don\u2019t forget to document and archive your work<\/h2>\n

Regularly take screenshots of the product in development for your portfolio! I keep forgetting this. I don\u2019t have a selfies mentality. However, maintaining a record for your portfolio\/case studies is necessary, and once a product gets updated, it\u2019s 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\u2019m doing and ensure I\u2019m not skipping steps.<\/p>\n

\"\"<\/a>I know you want to forget the brokenness in all its glory\u2026<\/p>\n

11. Don\u2019t wait for instructions<\/h2>\n

This point is self-explanatory. You\u2019re 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.<\/p>\n

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\u2019t 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"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.\"<\/p><\/span><\/blockquote>\n

Of course, there\u2019s always a small doubt in my mind that I\u2019m not doing something right and I lack guidance on the job. But it\u2019s always important to remember that just because no one is teaching you doesn\u2019t mean you are not learning. If you have feedback on any of the above points, I welcome your comments below. :D<\/p>\n

Originally posted Lai-Jing Chu's Medium<\/a>\u00a0page.<\/p>\n","protected":false},"excerpt":{"rendered":"

My \u201cfirst 90-days\u201d 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 \u2014 and can at least for a brief moment let out a sigh… Read More ￫<\/a><\/p>\n","protected":false},"author":310,"featured_media":18745,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[499],"tags":[],"class_list":["post-18713","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ux"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n