You don’t need ‘Research’ to Design
Of course Design can happen without its precursor being Research. Nothing really stops us from drawing up our wireframes or making our prototypes before asking the user some questions. Nothing stops us from creating a logo or deciding on the color pallet of a project. After all, we each have an eye for aesthetics and we are knowledgeable about application features. We are all creatives, right? You don’t need Research to Design,
But how else will you know what to design?
Often times we find ourselves in a position to make an existing application ‘better’. Let’s say you are a young freelance web designer and this application is a staffing company’s website, just for an easy example, and you take a moment to look over the existing site. You notice the visual design could use some updating — Drop shadows, bubbly navigation, and bevel on everything? Really?!
So the client invests money in your redesign of their website. You bring it out of 2005 and think it looks great! Having an understanding of current web trends, you add some updated features to the website as well. The client is happy and you have a shiny, new design to add to your portfolio! See? I told you you don’t need Research to Design.
Some time goes by and your client reaches out to you again. Their happiness has faded, and their frustration is very clear. Web traffic has stayed the same, their business hasn’t increased at all, and they are still receiving the same usability complaints from customers.
While the graphics did need updating, perhaps a little research would’ve shown you that the font was hard to read, the path to submitting a resume was difficult to complete, and there were no confirmation messages to let a customer know they really had successfully applied to a position. With a little initial research, you may have chosen different aspects of the website to re-work. Now you either lost a client to a competitor who does conduct initial research, or you are wasting time and money doing a job twice while doing a little damage control.
Then again, that’s just one example — you don’t need Research to Design,
But how else will you know who to design for?
Your client decides to let you take another stab at their website. This time around you’ve asked a few questions and now realize the changes you should have made the first time. After changing the paragraph font to Helvetica, reworking the path to submitting a resume on your client’s website, and adding some confirmation messages — and follow up emails, you witty designer! — you ask your roommate and close friends to take the website for a spin before handing it over to your client.
Your friends friends point out a couple of small adjustments that are needed. Aside from these, they praise your design as being quite the imporvement and love the modernity of the features. Your client is bound to be awestruck and forget they were ever upset with you and you eagerly submit the redesign to the staffing agency.
Time for some wine or a celebratory milkshake!
Not so fast…
Within a week of turning in your work, the client calls you and is less than enthusiastic. Your main point of contact at this company is an older man with limited technological experience. He records his favorite shows with his dusty VCR and calls you directly from his flip phone, barking, “I can’t get to our website. What is this?!” He must be referring to that lovely splash page you added to welcome and excite their customers. It’s complete with animations and an icon at the top left corner to skip ahead to the real content.
The trouble is that your client’s main audience is made up of older executives and high end accountant, many of whom will have the same trouble navigating the website as your client has expressed. In this round, you fixed the right problems, but you’ve designed this application for the wrong users.
You have lost this client’s business. It’s a bummer but it happens, right? This example doesn’t necessarily prove the need for Research, you were just a little shortsighted. I’m sure some common sense would’ve picked up on that stuff — You still don’t need Research to Design,
But how else will you know if your designs are effective?
Even if you think to ask the questions to find out where the problem is, and who uses the application, how will you know if your solution is effective (aside from recieving an angry phone call from your client)?
When you had your roommate and friends test out the second version of the site for your client, you were touching on another type of Research. Design and Development is cyclical; every…single…time. Even if you are not a part of each iteration of an application, good development is always repeating this process of Research-Design-Test. The idea is to always make things better and manage your static version of an application in a not-so-static world of users. In a redesign, such as the example you failed at, you could consider using testing at an early stage of your design and again at the end. You should also test in the middle… a few times.
Even with research and an eye for design, the user will be the pass or fail determinant for you product, so you should involve the user in the design and development.
I had a terrible science teacher in high school; he was the long-term substitute for our usual teacher. My classmates and I would study the material and come to class with questions. This teacher didn’t understand some of the topics and would give us wrong explanations. Many of us decided to teach ourselves the material while also noting his incorrect answers. When it came time to test what we’ve learned, we would answer certain questions incorrectly- per his explanation. When we did this we would receive credit for the questions even though we thought they were not quite accurate answers.
There is plenty wrong with that story, however, the lesson is sort of the same. Listen to whoever is grading you. Find out what the questions and answers of the test are; do Research to discover what it is that you are fixing in the design. Find out who will be interacting with your work; do Research to understand who the user is and how they interact with the application. Finally, hand in your work and receive feedback; conduct testing with your users and see what design decisions are working and what are not.
