Writing a Case Study

I hate writing case studies. Why do I hate them? Well, let me name the ways.

 

You write them in review

While it is often helpful to review a project and understand the journey, most people don’t take exact notes and are forced to make approximations of their thinking at any given time. Writing a case study makes it seem like projects take a simple linear path to improvement when this is rarely the case. Sometimes we will implement an enhancement and remove it 2 weeks later. Sometimes I will design an enhancement into a mock that we wont implement for 3 months while we play around with enhancements on other parts of the product. Or sometimes an enhancement will be the removal of features.

 

You have to go digging for images

While I love a well organized file system, it is not always easy to upkeep and to maintain an ongoing set of archived mockups. For the same issues listed above, mockups don’t always make sense in a linear fashion. Maybe I added a search feature on a page while I spent 2 months iterating on comment features before moving on to develop that search. Sometimes we ended up implementing search from one set of mockups and comments from another set of mockups.

 

Looking for sketches

I love sketching. I force my team to always start a project off with a white boarding session and advise them to stay on paper for at least the first couple of iterations of requirements gathering. But… I don’t always take pictures of these things and I don’t always scan my sketches. Sometimes I will sketch an enhancement, we will build it, and I will recycle to paper. Sometimes we will have an enhancement that doesn’t need any formal sketching and the white boarding session will be requirements gathering.

 

Copy Writing

Turning a case study into an easily digestible and intriguing story is hard. I find weaving 1-2 month chunks into a sentence or two does not do a project justice. Months of work can go into researching and understanding search. You have to make hard decisions like “is there a search results page or do we force the user to make a decision from a finite list?” You have to figure out visual language of identifying why something is in search results, what will be selected if the user clicks, what does hitting enter do, and where does the item you are searching for live. But the enhancement statement is simply, ‘implemented search.’

 

People don’t read

I have reviewed hundreds of portfolios and case studies and I do not read. So why would I expect someone to read my case studies? I don’t. So why do I spend time on it? Because I don’t interview people who don’t have full portfolios. This is a key item of a portfolio and no one is every going to read more than a few sentences. That’s why I keep mine brief.

 

Conclusion

I wish I didn’t have to write case studies, but I do. So I try to make the most of it and have fun. I might try to make a joke or two. I might try to make the reader a part of the conversation. Or I might stick to the facts. I guess it depends on how I am feeling that day… So why don’t you check out my work and let me know what you think.

 

A Long Delayed Thank You

There are many things that I am thankful for in my life. I have wonderful parents who pushed me to follow my dreams, despite those changing yearly as a teenager. I have wonderful siblings, who gave me the practical knowledge of how to get by as an adult. I am thankful to my wonderful girlfriend who has taken over pushing me to find happiness. But this blog is part me and part design, so this is post is about my first boss, Ed.

Ed was the director of a small design firm that was bought by my first company to be a dedicated design team. As the product started needing less design, Ed turned his gang of designers into a contracting crew to help provide revenue for the company. After 10 years, Ed saw fit to take his expertise elsewhere and took the gang on to his newest venture, UXL inc. Anyone who has asked me about design services, I always recommend them over to Ed(and now Julie too).

I recently realized how lucky I am that my first job was under Ed. Its now been 2 years since Ed and I parted ways, and as my roles have expanded… I realize how much he taught me in my time. I was recommended to Ed after I graduated from RISD by one of my favorite teachers. I was hesitant at first because I had recently interviewed at Digitas and after seeing a tiny bit of the work they were doing on the Taco Bell website, I thought that was what I wanted.

Ed decided to give me a chance as a designer, focusing on UX work despite having next to no experience. The design team focused on work inside the financial sector. According to my brother, an extremely talented web designer at the time, the financial and healthcare are where design careers go to die. But as a UX designer, finance is one of the most interesting and challenging industries I can think of. I spent the majority of my time contracted out to Morgan Stanley, working on their Wealth management platform.

Because of the connections I made with Ed, I was able to move to J.P. Morgan and work on their institutional bank platform. And because of the portfolio of work I was able to work on, I was able to get my current job working on both a social platform and a business solutions platform. As the lead of my team, I have recently been tasked with finding a new designer to join me. As the candidates have rolled in and the interviews have been conducted, I realized the gift Ed gave me all those years ago that I had no idea I might have been missing out on.

My first project at Codestreet was a SaaS enhancement. Since that day, I have either worked on SaaS or PaaS projects. As a UX designer, there is nothing luckier than to be introduced to complex software and platforms from the very beginning. I learned to think as a platform designer and how to think beyond the list of requirements presented to me. I learned to identify feature creep and how to push for missing requirements. I learned to love the complexity of something rather than just the visual appearance of it. And I learned that UX is emotional and the science behind it is theoretical.

I know I went a little all over the place here, but here is a very simple conclusion. Thank you Ed. You made me realize I would much rather be the guy designing the cash register at Taco Bell than the guy designing the Taco Bell website. You gave me a chance to experience our practice in one of its most challenging forms. And for everything, I am thankful.

 

Anyone looking for contract designer, reach out to Ed at UXL inc. They know what they are doing :)

Book Review: Neuromancer

Neuromancer, by William Gibson, is an interesting book, with important historical context. That being said, I didn’t particularly like it, but I still think it is worth a read if you are interested in Science Fiction. It was awfully confusing to this first time reader; however, it sets the stage for what has become one of the most intriguing genres of science fiction and fantasy – cyberpunk. Cyberpunk is a slight misnomer in that it doesn’t particularly have to be punky in how most people think of punk. Nerumoancer and the genre doesn’t have to have people with neon piqued vest hoodies rolling around on light based roller blades. It focuses more on the concepts of advanced information technology juxtaposed with the humane everyday life.

In Neuromancer we see this juxtaposition between Case, our wonderful black-hat hacker, taking on an artificial intelligence. We have the presence of Molly, our futuristic ‘muscle’ in the operation. We also have our villain that the heroes must heroically defeat. There is also a wealthy philanthropist, supplying our heroes with the money/equipment to take on such a task. And finally, we have the rest of the makeup of a thief’s ring, like a get-away driver, lower level hackers, and thugs who will be helping out on the mission.

If this sounds at all familiar or similar to the Matrix, it should. The roots of the matrix can easily be traced back to Neuromancer’s computer network, aptly named… “the matrix.” In an attempt to avoid any spoilers, I’ll stick to what happens in the first 1/3rd of the book… where nothing incredibly important to the plot happens.

Gibson gives us a very interesting look at a dystopian cyber future. He starts us off in what could be considered the slums. While reading about Chiba, I continually saw aspects of what would soon be called Midgar, from Final Fantasy 7. Midgar is a city of inter-connected slums that is below the inhabitants of the upper levels, where the wealthy live. Chiba does a great job of setting up the social commentary of the wealthy oppressing the poor. It also gives the reader the opportunity to sympathize with Case, despite all of his negative aspects.

Many cyberpunk stories can trace their legacy back Neuromancer and Neuromancer takes queues from many other stories. What it does well is inspire people who are interested in the technological future. What I find interesting is that even science and technology, what is thought to be a gleaming achievement of moving mankind forward, results in becoming dystopian when imagined. There is no Jetson’s just like there is no Flinstone’s. It is so easy for us to imagine the abuse of technology because we have seen so many things be abused before. 

I think the most interesting part of the book is the concept that technology doesn’t save us. People are still starving, despite the ability to make advances in food growth. People are still drug addicted, even though there are surgeries to remove drug addiction. Perhaps the minds of many writers are slightly negative and often force us down a pat of Dystopia. But the saving grace of this is there a millions of us fighting the abuses of power. We can look to the future in books like these and attempt to avoid the mistakes we took. One day, we may not need to read books like these.

Neuromancer, by William Gibson, is an interesting book, with important historical context. That being said, I didn’t particularly like it, but I still think it is worth a read if you are interested in Science Fiction. It was awfully confusing to this first time reader; however, it sets the stage for what has become one of the most intriguing genres of science fiction and fantasy – cyberpunk. Cyberpunk is a slight misnomer in that it doesn’t particularly have to be punky in how most people think of punk. Nerumoancer and the genre doesn’t have to have people with neon piqued vest hoodies rolling around on light based roller blades. It focuses more on the concepts of advanced information technology juxtaposed with the humane everyday life.

In Neuromancer we see this juxtaposition between Case, our wonderful black-hat hacker, taking on an artificial intelligence. We have the presence of Molly, our futuristic ‘muscle’ in the operation. We also have our villain that the heroes must heroically defeat. There is also a wealthy philanthropist, supplying our heroes with the money/equipment to take on such a task. And finally, we have the rest of the makeup of a thief’s ring, like a get-away driver, lower level hackers, and thugs who will be helping out on the mission.

If this sounds at all familiar or similar to the Matrix, it should. The roots of the matrix can easily be traced back to Neuromancer’s computer network, aptly named… “the matrix.” In an attempt to avoid any spoilers, I’ll stick to what happens in the first 1/3rd of the book… where nothing incredibly important to the plot happens.

Gibson gives us a very interesting look at a dystopian cyber future. He starts us off in what could be considered the slums. While reading about Chiba, I continually saw aspects of what would soon be called Midgar, from Final Fantasy 7. Midgar is a city of inter-connected slums that is below the inhabitants of the upper levels, where the wealthy live. Chiba does a great job of setting up the social commentary of the wealthy oppressing the poor. It also gives the reader the opportunity to sympathize with Case, despite all of his negative aspects.

Many cyberpunk stories can trace their legacy back Neuromancer and Neuromancer takes queues from many other stories. What it does well is inspire people who are interested in the technological future. What I find interesting is that even science and technology, what is thought to be a gleaming achievement of moving mankind forward, results in becoming dystopian when imagined. There is no Jetson’s just like there is no Flinstone’s. It is so easy for us to imagine the abuse of technology because we have seen so many things be abused before. 

I think the most interesting part of the book is the concept that technology doesn’t save us. People are still starving, despite the ability to make advances in food growth. People are still drug addicted, even though there are surgeries to remove drug addiction. Perhaps the minds of many writers are slightly negative and often force us down a pat of Dystopia. But the saving grace of this is there a millions of us fighting the abuses of power. We can look to the future in books like these and attempt to avoid the mistakes we took. One day, we may not need to read books like these.

 

Understanding Dumb LinkedIn Observation problems Volume 1.

If you have a LinkedIn and are connected to any sort of recruiter, sales, or someone trying to get more profile views, you have likely seen one of these really dumb observational problems. If you are at all like me, one occasionally catches your glance and you stare long enough to figure it out. If you haven’t, this can perhaps help you gain insight into what these people are looking for in your response. After all, my job as a designer is to solve problems.

First up in the dumb problem set: Which tank will be full first. What I like about this one is that it doesn’t offer a job to the first person to get it right. It feels a little less scammy about spreading poster influence into second and third connection and creating a larger group for the recruiter to add new connections from. It still will likely result in the same influence grab to gain potential new clients to place/sell or push up a personal profile to appear higher in search. LinkedIn is a professional career website, so it is no surprise that self-promotion is at the heart of posting.

 

The Answer: explained through stages

The original image

The original image

The first step to answering this question is investigating what kind of answer the originator is looking for. Often, they are trying to trick you so you feel special when you find the answer. This one has a trick to it and we will get there eventually, but first I’d like to answer it without the trick. We begin by examining the image. My first two observations are that there are 4 inter-connected buckets with open tops and one source of water.

From this step we need to begin inferring knowledge to understand how to solve this problem. The first assumption we will make is that the source of water will continue to produce water at a consistent value less than or around the value that can be transferred through the pipes. If more water flows into bucket one than it can transfer to bucket two, it will rise. The second is that the source of water will not move. And the third is that this is and will act like water. The next inference we need to make is to apply a knowledge of fluid dynamics to the image. We will apply our standard concept of gravity (things will go down) and our standard concept of path of least resistance. By doing this, we acknowledge the first act we need to do on the problem, we need to trace the pipes.

Image with pipe pathways drawn in

Image with pipe pathways drawn in

Bucket 1 has a pipe that connects to bucket 2. This pipe is slightly higher than the bottom of bucket 1, so there will be some water that must fill in bucket 1. By using the path of least resistance, we can assume water will flow through the pipe and start to fill bucket 2 because moving horizontally in gravity is easier than moving vertically. As bucket 2 fills, there is a pipe leading to bucket 3. Once again, a little water will be left in bucket 2 and bucket 3 fills, since it is lower to the ground. The next question is if the pipe from bucket 3 to bucket 4 will come into play?

 

Following the same logic, yes it will. As bucket 3 fills, so will the pipe. As bucket 3 reaches about 90% full, the pipe will start flowing into bucket 4. So bucket 3 and bucket 4 will eventually reach equilibrium. At this point we need to acknowledge water will begin flowing back into bucket 2 and filling all 3 buckets at the same rate.

If we do a very close pixel analysis, bucket 3 appears to be just slightly shorter than bucket 4. But ignoring that, we have our answer. Bucket 3 and 4 will be full roughly simultaneously and overflow at roughly the same time. But is that the answer? Of course not, there is a trick at hand. In fact, there are two tricks in this one. The first is the intended trick. There is a block in the pipe between bucket 2 and bucket 3. If we, once again assuming, that that block is air tight and strong… the answer is now bucket 2. Bucket 2 will fill with water before bucket 1 does.

Quick measurement of bucket 3 and 4

Image with marked observation trick

Image with marked observation trick

So what is the second trick? The second trick was likely not intentional, but it is still there. In fact, I find it a lot more interesting than if you saw the little black pipe blocker or not. The word full is contextual and beyond that is even cultural. So while the standard definition you are probably using is “containing or holding as much as possible,” another correct view is “having a lot of.” A glass does not need to be at max capacity to be said to be “full of water.” In fact, it is often only 70% or 80% full. Bucket 1 already contains water, so it is not inaccurate to say bucket 1 is already full of water.

Why do I find this interesting? It is rare that we take a moment to sit back and take for granted how much knowledge we have at our disposal. Observation, gravity, fluid dynamics, and language all played integral parts to solving this problem. We often call this a “common sense” problem, but it is anything but common sense. It required years and years of education to create a database of knowledge that can be recalled to answer a simple question like “which tank will be full first?” I find it miraculous the number of subconscious assumptions that we have to make in comparison to any of the decided actions that we took. While I hate these little things taking over my LinkedIn feed, I hope that we can all use them to occasionally remember how intelligent humans are and can be. Especially in a time where we feel so many unintelligent decisions are being made.

My Team

Creating a great team is about everyone having their place and their responsibility. This holds true from sports teams to work teams. In my case, I am part of three teams. The first team is my design team, a team judged on individual work ethic. The second team is the Product team, a team judged on unified mission. The third is the Engineering team, a team judged by success or failure. When I think about my team, I think of it like a football team. As a coach or team captain, you win when every single person does their part and they are all on the same page.

The design team is like a receiving core. Each of us has our own talents – speed, visual, interaction, complexity, etc… – and we rely on each other to help pick up slack where we might not be the best. But when we are working on our projects, we are the ones running the routes. I can’t tag in another receiver to run my route without stepping off the field and letting them run. And when the kid has a 'go' route (“go deep”) I have to let them run or they aren’t ever going to get by the defense. When one of us gets tired, the others are there.

The product team is like an offensive unit. We talk to stakeholders, we gather requirements, we set KPIs, we manage expectations, we get approvals, etc… Once again we all have our parts and our ways of contributing to the team, but our goal has shifted from running a great route to scoring some points. As a WR, I need to accept I’m not going to be the star of every play. Just like I have to accept there is some functionality I need to design that I don’t like and there are some meetings I won't be invited to.  No matter what the play is, our goal is to build better products for users and better products for the company

The engineering team is like THE team. The counterpart of the offensive unit is the defensive unit. And just like we have POs, PM, BAs, and Designers; the developers have Back-end, Front-end, dev leads, and operations. Put us together and we have a team capable of scoring points and stopping opponents (out-scaling the competitors). Some times the product team falls a little short and we need the dev team to help save us when we don’t have enough time to do discovery. And sometimes product has to support developers when requirements are being changed to fast for them to handle and we get in a shoot-out.

Once again, our focus shifts. Our goal as an engineering team is no longer to score points. Our goal is to win the game. If we win 3-0 or 35-0, it doesn’t matter. Sometimes we build amazing products, sometimes we build ugly products, sometimes we build products that are barely holding together under the surface.  But we build products, and when we ship them, we win as a team.

Afternoon Delight

A delightful design is rare. Everyone strives for it, yet it happens very infrequently. The reason it is so rare is because everyone has a different definition of what delightful is. Recently our head of sales told the company it is “up and to the right” of expectations crossed with whatever else they are feeling.

To me, delight is not meeting expectations. Meeting expectations is… expected. Delight happens when a user has an objective, they don’t know if they can achieve it, and it turns out it is easy to complete. There are some products that delight me over and over again, but most products have one shot and they need to capitalize.

Last week there was a huge rainstorm coming through New York and I had tickets to go see a movie with my girlfriend.  She texted me that afternoon, right before the downpour started, worried about that night and the impending flood. So I pulled up the ticket confirmations in my email. Scanning the email, it took me almost no time to find what would normally be an inconspicuous link labeled “can’t make the show?”

That was all it took. My response was, “sweet, I didn’t know if I’d be able to do this.” It looked like I didn’t have to lose the tickets. Maybe someone who was willing to trek through the rain would be able to go in my stead and I would be able to get tickets another night without having to pay extra money.

I was greeted with a log in screen and after logging in I was given a simple choice, refund my credit card or refund for credit towards my next purchase. No hidden attempt at trying to keep me from exchanging the tickets. And the next screen was a confirmation. I looked up the movie for the next day, selected the tickets and it showed me the cost, minus my refund. (It was zero)

That was all it took to delight me: a simple link, a simple product feature, and honesty.  That is all it took to win my business from now on. It wasn’t a beautiful screen or fancy animations. It was giving me a feature I needed, but didn’t know was possible, and making it dead simple to use.  That is good design, Fandango.