The Role of a Designer in an Application Security Company
Having recently started at nVisium as a designer, my role in an application security oriented company is clearly unlike most others on the team. I joined the company as part of the effort to expand the new development team while the majority of my colleagues are in the consultation service that the company has its roots in.
As for myself, I am a graphic designer by trade, with some side knowledge of front-end web development and user research, yet my job so far consists of 70% front-end development, 20% user research, and 10% graphic design, which means most of the time I am given the challenges outside of my realm of familiarity. But that was not my foremost concern.
Here are some of the things I have noticed in the past four weeks:
Whenever you become part of a new environment, there will be the initial learning curve of trying to understand how to work with everyone, as people have different working styles. However, joining the team bearing a new role steepens that curve quite a bit. On top of adjusting to the personalities and work habits, it was quite evident that the question “Can I ask Hong to do this?” was always being asked because the team did not have a dedicated in-house designer prior to my arrival.
I used to work with designer peers, so it was not until I joined nVisium that I realized the amazement people can have toward my work. For example, I recently produced this logo animation in a two hour time frame:
…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.