Because Ping An is a financial institution with an elevated focus on information security, I am bound by an NDA that forbids the disclouse of more details of the product.

What I can say is that my day-to-day involves collaborating with a cross-functional product team: I received and revise Product Requirement Documents from Product Mangers, produce UX mockups and oversee that the design is translated into high-fidelity mockups and satisfactorily implemented by developers.

My design efforts included improving the over all messaging experience, optimizing audio/video conference experience and various localized new functions and redesigns. And below is a small portion of the UX mockup for the conference experience.

But in the relatively short time, I have had a lot to learn and took away with much:

1. Constantly reflect on assumptions and on conceived ideas and challenge myself to not dwell on a single idea/concept: I know this as a designer from the very beginning, but having ideas challenged in work from aspects that I genuinely did not think of has made a lasting impression on me to seek out more context, edge cases and consider the complications of my design decisions further before deciding. For example, when designing a casual discussion section for our product, I included a time stamp for each post. But it did not occur to me that a portion of the users do not want their superiors to see them posting during work hours, another portion do not want to be bothered by seeing their subordinates posting during work hours.

2. Work within constraints, but think outside the box: There are many constraints working on a real-world product, but that does not mean the final solution has to be constrained. And I have learned to use constraints to better channel my efforts and be more creative in a focused area.

3. Working with ambiguity: Always ask for more information when in doubt. This one seemed obvious, but at first I feared that I might appear incompetent, but I quickly realized that producing sloppy results due to incomplete information is true incompetence.Contribute individually in different parts of a projectWhen I pursued a UX/Product design career, I thought I would be working on each and every project from the ground up: researching, synthesizing, brainstorming and finally producing a prototype.
But during this internship, I learned that as an individual contributor, I usually do not fully participate in that entire process, and the bread and butter of the work is oftentimes crafting a part to the best of my ability within a relatively short timeframe. Although it is not what I originally expected, I have found myself enjoying it as much, and have adjusted my expectations accordingly. Work and cooperate within a big organization

4. Balancing business and user goals: As designers, it is our nature to advocate for the users, and I had done so faithfully in the past. But within a large for-profit organizations like Ping An, business goals have taken a more prominent role. And I have learned to consider and balance that with user goals.

5. Minimize friction in collaboration: My prior experience working on individual projects and within small groups gave me the tendency to dig deep early on. But in a big company, communication could sometimes be laggy, so I have learned to start with definitions of key behavioral and contextual elements, and communicate with stakeholders and peers at incremental milestones and receive feedback along the design process.

6. Back and forth with stakeholders: In the process of presenting and then receiving feedback from the stakeholders, I have learned to maintain a clear focus on the relevant part and a cohesive chain of justification. And I can better access when to stand my ground and when to consider revisions.

Having my ideas challenged from aspects that I never thought of has made a lasting impression on me to seek out more context, edge cases and consider the complications of my design decisions further before deciding. For example, when designing a casual discussion section for our product, I included a time stamp for each post. But it did not occur to me that a portion of the users do not want their superiors to see them posting during work hours, another portion do not want to be bothered by seeing their subordinates posting during work hours.

There are many constraints working on a real-world product, but that does not mean the final solution has to be constrained. And I have learned to use constraints to better channel my efforts and be more creative in a focused area.

During m‍y prior experience working on individual projects and within small groups gave me the tendency to dig deep early on. But in a big company, communication could sometimes be laggy, so I feared that I might appear incompetent trying to asking questions. But I quickly realized that producing lesser results due to incomplete information is true incompetence. So I have learned to start with definitions of key behavioral and contextual elements, and communicate with stakeholders and peers at incremental milestones and receive feedback along the design process.

‍As designers, it is our nature to advocate for the users, and I had done so faithfully in the past. But within a large for-profit organizations like Ping An, business goals have taken a more prominent role. And I have learned to consider and balance that with user goals.

In the process of presenting and then receiving feedback from the stakeholders, I have learned to maintain a clear focus on the relevant part and a cohesive chain of justification. And I can better access when to stand my ground and when to consider revisions.