We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.
Jeremy Girard was born with six toes on each foot. The extra toes were
removed before he was a year old, robbing him of any super-powers and
ending his crime-fighting career before it even began. Unable to battle
the forces of evil, he instead works as the Director of Marketing and Head
of Web Design/Development for the Providence, Rhode Island based Envision Technology Advisors. He also teaches website design and front-end development at the University of Rhode Island. His portfolio and blog, at Pumpkin-King.com, is where he writes about all things Web design.
Earlier this year, I was in the beginning stages of a redesign for our company’s website. We had already been planning to use a straightforward responsive approach to Web design, which is our preferred solution for multi-device support.
After hearing some frank discussions at An Event Apart conference in Boston about the limitations and challenges of responsive Web design, I realized that our solution needed a bit of adjustment.
Everyone loves a happy ending: the hero slays the dragon, true love conquers all, the Death Star is destroyed, the new website is launched and both client and users alike are thrilled. While this last example may not have the Hollywood ending that the first few examples do, for those of us in the Web design industry, it is the story ending we want for all our project.
Much attention is given to how you kickoff projects, or how best to design and develop websites. But the final stages of the Web design process are never discussed as much as those early and middle stages are. How you wrap up a project, as well as what you do after the project is completed, is critical when it comes to building long-term relationships that will lead to future business.
In this article we will look at some ways in which you can end projects on the right note, and also what you can do after they are launched to help your project stories have happy endings (and many successful sequels).
Poor communication is a surefire way to damage any project or relationship, but when I dug deeper into this particular case, I realized that lack of communication was not the issue; the company provided regular updates on projects and milestones and so on. Rather, it was the words they used when giving those updates and answering questions. The problem was that the provider spoke “Web speak” and nothing else. [Links checked March/06/2017]
This isn’t the first time I’ve heard this complaint from someone when discussing their Web team. While they appreciate the provider’s knowledge of the profession and industry, they bemoan the reality that they cannot translate that knowledge into language that someone who is not a fellow Web professional would understand. While the updates may be plentiful, the communication is still poor.
As Web designers and developers, each project we work with has a unique set of goals and requirements. But one goal we have for all of our projects is that we want them to make an impression on people — we want the websites that we create to be memorable.
A fun experience is often an enjoyable one and an enjoyable experience is usually a memorable one. Therefore, it stands to reason that one of the ways to create a memorable experience is to make it a fun experience. In this article, we'll take a look at how adding a bit of "fun" into the mix can help us produce more engaging, and hopefully more successful, websites.
We often hear companies, including Web agencies, boast about how they provide exceptional client service. But how do they define exceptional? Consider this scenario. You are hired to design and develop a new website for a retail client. The client loves the design, and the pages you develop use the latest in HTML5, CSS3 and responsive design, resulting in a website that works wonderfully across browsers and devices.
The e-commerce features of the new website help the client significantly increase their online sales, and the entire project is delivered on time and on budget. Now, is this “exceptional” client service? I don’t think it is. When the client hired you, they expected that you would design and develop a great website. They also expected it would be done according to the timeline and budget set during the planning stages of the project. As successful as this project may have been for both you and the client, in the end, you did exactly what you were hired to do. You did your job.
There comes a point in the career of many Web designers where the logical progression in that career is to take on a leadership position. A logical step or not, when a designer "assumes" this type of a position, there is often another "assumption" happening at the same — that wizard-like proficiency with HTML and CSS, coupled with a number of years in the industry, equips someone to take on a leadership role. This is, of course, not always the case.
Over the past few years, I have gone through this transition myself, moving from a Web designer to a Creative Director to my current role as the Director of Web Development. During this transition, I turned to the blogs and other resources that I had found helpful in my career to that point, looking for tips and lessons that would help me in my new role. I quickly realized was that while there are countless articles to help you become that aforementioned HTML and CSS wizard, there are precious few that deal with the move from designer to director.
Websites are designed to be used by people of varying backgrounds, educations and technical levels. One of the challenges we face when designing for the Web is finding a way to create sites and applications that can be accessed by a widely disparate audience while avoiding the pitfall of sacrificing the quality of our work to cater to the dreaded ‘lowest common denominator.’
Even though it happens to me with some frequency, being told by a client that one of the requirements for their project is that it must be ‘idiot proof’ never fails to give me pause. The sentiment itself is offensive enough, but the concept also seems somewhat misguided to me. Do we really want to begin a project by assuming our site's users are idiots?