…and it led to our CTO, Ken Johnson, jokingly telling me, “From now on I am just going to shut up and let you do whatever you need to do.” While it is indeed pleasant to receive positive encouragement, this is problematic as well because (1) I am aware that I am not a magician and my knowledge only covers a few fields of design, and (2) my colleagues trust that I always have the ultimate say with anything design-related, leading to hiccups in feedback, which I will explain in the next point.
The importance of feedback cannot be overstated to design professionals. Unlike code, a design can only be evaluated by observing other people responding and/or using it. In an environment where there is more than one designer, members within the team can critically assess and critique each other’s work as it develops over time, thus producing products with finer quality before they go out to the customers. It is trickier in my current situation as I am the sole person in such role. Once in a while, I will find myself stuck with nuisances that would otherwise be easy to resolve if there was another pair of trained eyes. However, there are times that I do receive suggestions that are valid and yet not applicable because of the constraints of time, resources, or experience. In this case, offering an appropriate rejection is a delicate matter: You certainly do not want to give the false impression that only you are entitled to say “yay” or “nay” in a design process because that will stall the feedback loop and sour your relationship with your colleagues.
Prioritization of Tasks
I thought I had a lot of tasks while I was in college, but working for a startup has taken the challenge of managing my tasks to another level. At any given moment, there are at least 10 things that need to be done, and most of them can be broken down into smaller parts, doubling or tripling the actual number. It can be as small as increasing the leading of a text paragraph on the home site, or as time-consuming as putting together a graphic style guide (which can be broken down into at least 6-8 parts) to be used until a rebrand is introduced to the company. The battle between time and ROI is constant as I move from one thing to another. To use an example, I use a mind map to manage my to-do list and my tasks translates to something that looks like:
Importance of Security
This is the most fascinating part of all because it defies all of my previous knowledge—We are a security company so oftentimes the importance of security is more emphasized than other factors, even if it might sacrifice UX slightly. To give an example: Just last week, I was discussing with Ken about the inclusion of reCAPTCHA to our home site contact form and whether or not it turns away users who find it challenging to use. This is not to say we do not value UX in our development; we are simply well aware of how insecure features can cause harm to both ourselves and our users in the long run. In a non-security based team, usually it is the, if not the most, overlooked part of the operation. In fact, I have been in situations where million dollar proposal documents are transferred many times through insecure networks that can be easily intercepted, but I wouldn’t have known this until I started learning secure practices from my current colleagues.
My observations thus far have led to a single question: What are the most crucial responsibilities I have as the first designer of the team? Considering that I just joined not too long ago, I do not have a comprehensive answer yet. It is safe to say that there will be a follow-up post on this topic a few weeks down the road. Until then, let’s see if I can trim down my mind map faster than it further branches out.