Blog

Why Research Should Be the First Step of Every Technology Project

September 29th, 2014 by LookThink

Kicking-off a technology project, whether it be a website, portal, reporting system, or consumer-facing application, is exciting. It’s probably been a topic of conversation in your office for a long time, so you’re anxious to get started as soon as possible. You’re dreaming up functionality, color palettes, integrations – all the things that are going to make you end-product stand out in the crowd.

We completely understand your fervor to get started. We really do.

But have you thought about conducting research on your current and future user-base before solidifying your plans? Because – wouldn’t it be helpful to create an evidence based plan that allows you to craft messaging, organize functionality, prioritize offerings, etc with confidence?

As an internal stakeholder, you will never be able to put yourself in your users’ shoes. Only your users can provide the type of unbiased feedback that will point your new or revamped tool/site/system in the right direction to achieve the financial goals, engagement rates, retention numbers, user interactions, etc you are seeking.

All that said, reserving space in your budget and/or project calendar for user research is so commonly ignored or overlooked. But it shouldn’t be regarded as a delay in your project start-date or an unexpected cost that weighs down your budget.

Here are three great reasons to make research the first step in your project plan:

1. Knowing your targets users ensures that functionality anticipates – and delivers on – their needs.

When you take the time to understand your users and how they interact with your product, amazing realizations come to light. Let’s say you are creating a mobile app for an online banking website. You could simply repeat the desktop experience – OR – you could poll users to find out what functions they use most on-the-go. Make sure those functions (perhaps mobile deposits and fund transfers) are front and center on the app dashboard screen – and your users will never need to hunt for the functionality they rely on most.

2. Surveying the competition makes you smarter.

In addition to researching your users, it’s key to conduct competitive analysis of other companies in your industry. Analyze their approach to determine what they are doing well and what they are lacking. Remember to consider the public’s perception of your competitors as well. You never have to go far to find user reviews or blog posts and those can be very revealing. If you are able to conduct user interviews or focus groups, these are great opportunities to speak with your competitors’ customers and discuss the reasons behind their allegiance.

3. Research ALWAYS saves time and money in the long run.

Conducting research helps to avoid the missteps that would inevitably be uncovered during user testing. Making changes during the initial phases of a project – when you are strategizing, sketching, and solidifying requirements – are infinitely more economical than attempting to change functional or design features in the final stages of a project. When you research first, it’s less likely you will need to make drastic adjustments during development because you had your user in mind when building – and that means your project stays on time and on budget. What could be better?

Have questions about our research practice? We would love to chat!

 


2014 Summer Synopsis from the Snarky Intern

August 18th, 2014 by LookThink

Friday marked the last day of Sarah’s summer internship with us and we were oh so sad to see her go! We were undoubtedly spoiled by her enthusiasm and willingness to take coding projects by the horns and we will certainly miss her can-do attitude. We wish her the best of luck in her remaining semesters at RIT. Check out her parting words below and follow her at @Sarah_federman.

Dear Lookthink,

Oh, hello! I guess it’s the end of the summer, isn’t it? I figured Lookthink deserved a shoutout for providing an amazing internship experience. Thanks, Lookthink! You rock! (Do I get a hoodie now?)

Being a part of the Lookthink team is an experience in and of itself. I’ve never met another group of people that consistently beat me to the sarcastic one-liners. LT cultivates a productive, fun, witty, and creative culture in the office, which is imparted in everything we do. See how I said “we?” They’re super inclusive, too.

But sadly, it’s time to get rid of the “we,” and go back to “they.” Here are some closing thoughts and things I’ve learned:

1. Being the only intern in a small office, I had a lot of responsibility when working on projects. No coffee runs…unless Nate wanted his pink sugar. I learned a lot about time management and when to ask for help. Being self-taught with most of my programming, I’m used to turning to Google for answers and sifting through document after document. It took me a little while to realize I had an entire office full of knowledgable resources with valuable experience. It wasn’t “giving up,” it was asking for help. A team member with years of experience is infinitely more valuable than a vague stack overflow answer.

2. In my interview, Joe asked me, “Do you think you have much more to learn about CSS?” And I came up with some answer about how CSS is constantly changing and needing to learn more and more as it evolves. And that’s true, but I really had no idea about how many little things I didn’t actually know about CSS. These things became wildly apparent to me as I took on bigger projects.

I read something recently about learning web development. It said something like: “It’s very easy to start learning front-end web development. But it’s very difficult to get good at it.” This rings so true to me now. I may have a solid footing in the basics, but I have a ways to go. I’ve learned a lot working here, but I’ve realized the dangers of complacency. There is always something new to learn, even if it’s something as small as understanding how browsers process :nth-child selectors (Thanks for that one, Greg!).

3. A long, long time ago, I did a very small amount of freelance. I did whatever the clients asked, because they were the ones paying. But from watching Molly and Rachael, I’ve learned that part of what clients are paying for is your expertise. The best clients are the ones that realize this and work with us to compromise. Blindly doing whatever a client asks is almost dishonest. You have a responsibility to work with them to create a better solution. Again, it’s a balance. The best work involves plenty of compromises.

4. Learning on the job is really amazing experience. I had never touched PHP or WordPress before this summer, and I had never put what I knew about sass and sass frameworks into practice. It’s super rewarding to hit an obstacle, overcome it (with help, sometimes), and see the results in a tangible finished project.

This is getting too long. But there’s plenty more, I promise. Side notes:

Random things I will definitely miss about Lookthink:
- The weekly meeting intro questions. You guys have such…interesting…answers.
- Bethany’s swearing. At everything.
- Joe’s check-ins (especially over lunch)
- Molly and Rachael squealing about cute baby things.
- That one time the massage therapist started talking about rainbows. Or something.
- Trying to get answers from Greg. Out-snarked every time.
- Nate’s tacos. Yas.
- Dropping absolutely everything to watch the The World Cup.
- Erik talking about the World Cup.
- Randomly running into Chris on the commute. Chris realizing that I’m next to him, 5 minutes later.
- Jihye’s shouting at the top of her lungs. Every day. (…not really.)
- Goodshuffle jokes.
- Vim jokes.
- Working on three screens. How will I ever go back?!
- Hip Hop Fridays.

…etc. etc. etc.

Aaaand things I won’t miss:
- Fireworks.
- IE8 Compatibility.
- Temporarily Broken A/C.
- Missing ALL the movie references because I’m a baby.

…That is all.

So I just wanted to say thanks again for a great summer. I learned lots. I will try my hardest to take it with me wherever I end up next.

Sincerely,
Sarah Federman

P.S. Do I get a hoodie now?


LookThinkLink: August 7

August 7th, 2014 by LookThink

1. Scrolling Experience

There are many methods to enhance the look and feel of a site and implementing a scrolling experience is one of the most popular methods today. Check out MACAW‘s redesign – we’re digging the colors, icons, succinct content, and powerful testimonials.

MACAW

2. Inspiration

Like bikes and art? Looking for some creative inspiration? “100 Hoopties is a design challenge project where every day for one hundred days – an iconic poster design will be reanimated through scrapped bicycle parts.” Which one is your favorite?

100Hoopties

3. Illustrator Exporting Tips

Ever wish you could export multiple Illustrator art-boards in a PNG file? Oh you can. Check out this post that has a few scripts that lets you do just that. Useful, huh?

IllustratorExporting

4. Pure CSS Off-Screen Navigation Menu

Hiding a website’s primary navigation has become a vital component to responsive website design. Did you know you can accomplish that with pure CSS? This article will show you how to make a simple version of the off-canvas menu and sliding effect using only CSS. Pretty cool stuff.

CSSoffScreen

5. Great Distraction

Need five minutes away from whatever your working on? Check out this animation.

Distraction

 


BEM, Sass, and Semantics

July 25th, 2014 by LookThink

Today’s post is brought you by our fantastic summer intern, Sarah Federman. Sarah is a New Media Design major at the Rochester Institute of Technology and has brought her A-game to our Development team. From spearheading website builds to supporting the design team, Sarah has played a major role in the projects flowing through our office this summer. Follow @sarah_federman on Twitter for the latest and greatest in bleeding edge techniques for front end development!

There’s a nice buzz around the topics of modular CSS and CSS Preprocessors these days, but do they go hand in hand?

If you haven’t heard of it, BEM stands for Block-Element-Modifier, and is a syntax system and philosophy for creating flexible css modules. You can read more about it here: http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

I recently started working on a news site that displays articles in several distinct ways. Thus, the easiest and most reusable abstraction was to create a module for displaying article information.

My blocks included things like:

.article__title
.article__date
.article__description

One modifier is for displaying articles in a tile-like grid format

.article—tile

…but they’re also styled differently in the footer:

.article—tile—footer

Add in more modifiers for promoted “sticky” tiles, featured articles, articles that go within a media object, articles overlaying an image…and suddenly you’ve got a sizable module going.

I started out going as Sass as possible, with something like this:

.article {
  &__title {}
 
  &__date {}
 
  &__description {} 
 
  &—tile {
    &__title {}
 
    &__date {}
 
    &—footer {
      &__title {}
 
      &__description {}
   } // end footer
 } // end tile
 
 &—media {}
} // end article

…And so on. And suddenly we’ve nested 6 levels down 350 lines. It might compile something pretty, but right now I’m looking through my own file and all I see are ampersands, and I’ve scrolled down and I can’t orient myself. Am I still looking at a tile? Am I back in the article root? Could someone else read this? Would this confuse my team members? Extending blocks closer to the root is suddenly complicated as well.

It’s ugly and un-semantic. Is it theoretically well organized? Sure. Maybe I could have heavily commented, but I ended up taking out all of the ampersands and switching out of pure sass.

.article{}

  .article__title {}
  .article__date {}
  .article__description {}
  
  .article—tile {}
  
    .article—tile__title {}
    .article—tile__date {}
    
    .article—tile—footer {}
      
      .article—tile—footer__title {}
      .article—tile—footer__description {}

400 lines in, this is much more readable and easily maintainable. There are some places where I might consider making “article—“ a variable. This method certainly takes much more typing, but I think it’s worth it when it comes down to maintenance and semantics. Extending is also much easier.

Sass is still great for all sorts of functionality, like mixins and creating partials for your modules. I love Sass. But personally, I would caution against sacrificing semantics for quick typing.

If I were to redo this, I might break it down further and start making more classes with less that I could use together in the HTML instead of extending the other blocks and rewriting rules.