Image for post
Image for post

Before I landed my current position I spent some significant time interviewing for various senior design positions at a variety of companies. Overall these processes were similar. They started with a vet from a recruiter, then a conversation with a hiring manager, a portfolio review and then often an in person interview as a final step. Yet I found the real variable in this process to be the take home “design test” and after a while I found these tests showed me a lot about the company that was administering them.

The “design test” is a task administered by companies to design position candidates, ideally in order to discern the candidates process and work ability in a controlled scenario. In general I am not a fan of design tests. Firstly, I know few other industries that ask candidates to do the work — that they will eventually be hired to do — for free before they have an employment offer. A lawyer friend of mine recently accepted a job at a new firm, they didn’t ask him to do a mock trial beforehand to “better understand his process”. Why are designers different? If a designer has a decent resume, real work experience and a portfolio that can be reviewed in depth, it should be enough information to tell a hiring manager what he/she needs to know about this designer’s track record. …


Taking a break from my regular UX writing to share something I just created. I am constantly tweaking my portfolio and at some point I realized it was time to implement a lightbox for the images I display. Buuuuuttttt…I didn’t want a plugin or anything too heavy. Just something simple to make the images appear in a modal and a little larger than they are on the actual page.

So….I wrote it myself using (gasp!) Jquery. But, if you’re looking for something bare bones and extremely easy to implement I present the Really Really Light Lightbox to you:

Jquery Code:

<script>

$(document).ready(function() {
$(‘img’).click(function() {
var modal = $(‘.modal’);
modal.attr(‘src’, $(this).attr(‘src’));
modal.css(‘display’, ‘block’);
$(‘.background’).css(‘display’, ‘block’);
$(‘.close’).css(‘display’, ‘block’)…


Image for post
Image for post

The other day I was logged into my Gmail account when I saw a small message overlaid on one of my emails asking if I wanted to follow up on said email. It had been 5 days since I sent the email. A google bot had crawled it, read it, understood I was asking a question of the recipient and then logged that I hadn’t gotten a response yet so it prompted me to follow up on the issue. Was the interaction helpful? Sure. Did it give me the chilly feeling of being totally invaded of my privacy? Definitely.

I think many of us in 2018 understand, on an intellectual level, that the data we host online is not private. We are reminded of this with updated privacy disclaimers, breaking news stories, court cases and lots and lots of social media ads clearly geared towards our individual interests. Yet, I believe there is still an element of cognitive dissonance among many users that the information stored in our password protected applications maintains some semblance of privacy as well; which allows us as users to interact with these applications in a blissful and somewhat uninhibited manner. Interactions that challenge that perception, even when helpful, can be unsettling to us. Yes, it was nice of google to remind me to follow up with my colleague, but it was equally creepy being so blatantly confronted with the fact that google was reading, understanding and tracking the content of my emails. As a UX professional I am writing this article not to engage in a debate over the ethics of collecting users’ personal data but rather, in our current reality of interacting daily with these applications, I am concerned with creating an environment that allows users to comfortably engage with applications with minimal voyeuristic reminders of how public our data really is. For those users who either don’t realize how much data is recorded and mined from our interactions on these applications or just don’t like to think about it on a regular basis, interactions like the one previously mentioned break that fourth wall and have the ability to change the experience of using an application from enjoyable to unnerving. …


Image for post
Image for post

I recently finished a project for a web application that the company I work for is releasing. This project was a tough one, requiring a lot of approvals, iterations and lots and lots of testing with a vastly diverse group of users. The end product is a solid, well researched, well tested series of interactions our team can be proud of. But, here’s the clincher, it’s not sexy.

I work for a company that built and maintains a license management software. We design, update and troubleshoot a series of web (and soon mobile) apps that our clients use to manage their license portfolios. For example, if a large liquor store chain needed to keep track of all its alcohol licenses for its various stores it would use our application to do so. It’s good work, it’s necessary work and, at times, extremely challenging work but it isn’t “cool” work. My team and I do a lot of data designing and work within the bounds of many of unique customer requirements and restrictions. These often lead to UX friendly but somewhat visually unspectacular designs. And there was a time in my career when that would have really bothered me. When I graduated from college I too wanted to work at a Brooklyn based startup, designing a new and innovative interface for the next killer app. Instead I wound up a junior designer at a large, well respected electronics ecommerce. And though my work wasn’t necessarily always Dribbble-worthy, I found myself working on challenging customer facing issues, working with an awesome and well-seasoned UX team and learning a TON on the job. …


Image for post
Image for post

I’m starting to feel like Alice. I followed the White Rabbit down the rabbit hole and now I’m falling farther and farther into the abyss that is designing without any user data. Let me explain: A few months ago I wrote an article about my experiment in “Self Design” and what a UX designer might do in a sticky situation in which there is no user data for the problem he/she is trying to fix. In my case the interaction we were (and still are) designing was to be sent along a chain of command and to which end users we were not allowed access to poll or consult with; a challenge in itself. As I wrote in my article, I followed my own protocol to test our product and our solutions doing the one thing all UX gurus advise not to do — make myself the primary user. All in all, that stage of design panned out as decently as I could have expected and still remains a viable solution for a designer forced to work in isolation from end users. …


Image for post
Image for post

Addressing the “Design Vacuum” Conundrum

Thankfully, as a UX designer, I rarely have to design in a vacuum. I have myriads of testing tools, prototyping tools, simulation tools and customer contact lists at my fingertips to make sure that my designs are tested until they can be tested no more. And then tested again. But I digress. Though it happens infrequently — as many statisticians can attest to — there’s always that margin of error — that 0.1% chance — I do come up against a design project with no customer feedback or information; and then my question becomes: what now?

Becoming My Own Audience

Rule #1 of UX design is: you are not the target market. You know the old idiom “you know what happens when you assume…” This holds very true for UX design. Know your target audience, do your research, test your findings and design smartly. But what is a UX designer supposed to do in those moments when we find ourselves designing in a vacuum? I was forced to ask that question of myself when I received my most recent assignment. For various reasons the project given to me — though the end product would be customer facing — was completely divorced from user context or feedback and was being dictated solely by an internal partner who wanted to see it signed, sealed and delivered as quickly as possible. (We can debate from now until the end of time as to whether or not we should be encouraging tasks like that but — since I still need to pay my mortgage — sometimes it comes down to doing what the boss tells me needs to get done.) After asking all the questions I could of the product owner (in this case: my boss’ boss) I was then tasked with the challenge of setting out to see how much practical data I could collect and did something I try to never do: I made myself the primary user. Jared Spool refers to this type of designing as “Self Design” (5 Design Decision Styles. What’s Yours?). It is an uncomfortable place for designers to find themselves because it’s extremely hard to look beyond our own experiences and design effectively for an environment we can’t immerse ourselves in or at least become familiar with. Yet, when the need arises, using yourself as the primary test subject for a design can sometimes provide real world context for design decisions when none exists otherwise. This seemed like the best solution to my current vacuum dilemma. …


Image for post
Image for post

As the only UX designer at my current company I wear many hats when it comes to the design process. Yet the hat I was asked to wear today provided me with an insight I hadn’t expected. Not an earth-shattering revelation, but definitely an informative one. Today I was asked to wear the hat of “front end developer” for the first time — meaning that I was asked to simply translate a high fidelity mockup I’d received into code and not provide any personal design input. My marketing director needed a project to go live and since I have a coding background I was pulled from my usual responsibilities and utilized as a developer for the day. And no sooner was I given the mockup then I was reminded of a debate that I’d previously refrained from picking a side on: is familiarity with code an important skill for a web designer? …

About

Michal Lenik

Senior UX designer at Lighthouse 360.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store