By Kevin McGillivray
We just finished up a major project at my agency: a new website for our company.
You can see the website here.
In my experience, designing for yourself is a uniquely difficult task compared to designing for a client. I think it’s hard to get a clear perspective on the project and hard to decide what to do because you’re so close to it. This project had those difficulties, but it was also very fun to work on, and I’m very happy with the results. I learned a lot from working on this site, and I think the things I learned from it are also what made it so enjoyable to work on. Here are a few of those things.
In the past, projects within the web development team at Insight have been pretty solitary. Usually only one developer would work on a project and there was no easy way to share our code and work together. When someone needed to update a site that another developer had built, things would get confusing because files would get out of sync and we didn’t have a shared understanding of the site’s code.
For this project, we focused heavily on collaboration. We had impromptu feedback and dicussion sessions almost every day. This kept the design process focused on team conversation rather than just one developer presenting to everyone else. It also meant that ideas were strengthened because of the regular feedback.
On the technical side, we also used this project to as an opportunity to integrate Git and Github into our process so that we could share the site’s code with each other and all be familiar with it and work on it simultaneously. This alone transformed our process from being almost purely individual to being highly collaborative, and it will have far-reaching effects on how we handle every website from now on.
This collaboration was a major part of why the process was fun, exciting and energetic. Everyone could jump in and be a part of it, and we all felt like we were working toward a goal together.
One of my main goals at the beginning of the project was to work in a way that was flexible. I wanted to be able to change things easily, keep things simple so that as we came up with new ideas we could try them out without wasting time. This efficiency is essential to keeping a project moving and enjoyable. If things slow down and don’t feel like they’re going anywhere, the energy disappears and the project becomes discouraging.
Our previous approach to web design was less flexible. We would make mockups of websites in Photoshop and send those to a client for approval. Once approved, that would be the final design we would make. If a change needed to be made, there would be some resistance to making the change because of all the time invested in perfecting the photoshop mockup, and fear about going over budget as a result.
This time, we switched our mindset 180 degrees. We specifically welcomed changing our minds in the middle of the process. We worked quickly and roughly, not worrying about perfection in the beginning stages so that we didn’t have to worry about wasted time. If someone had a new idea, we’d try it out as an experiment. We’d commit to ideas and see where they went, and because we were flexible and quick if they didn’t work we had enough time to backtrack and change our minds.
This flexibility was only possible because of our discussion based collaboration, but the collaboration also wouldn’t have worked if we didn’t have a flexible mindset in the first place. Experimenting, playing around with and testing ideas, and making clear regular progress on a project is a lot of fun.
We didn’t make a single mockup of this website while designing it. Everything was designed into code right away. Not only does this cut down on having to do the work twice (first doing it in Photoshop or some other tool and then doing it in code), but it’s also the only way to know if something is really working or not.
When I show a client a flat, non-iteractive mockup of a website, they’re not getting the real experience. They see an entire page at once rather than thinking of it within the frame of a browser. Websites are flexible, interactive and change over time. Mockups are the opposite. They also encourage a focus on just the visual style of a site, so they change the type of feedback you get compared to when someone can experience the interactive elements as well.
With this project, we dealt with reality rather hypothetical possibilities as much as possible. If we had an idea or we weren’t sure how something would work, we built it for real and found out, because that’s the only way to find out.
Published 23 July 2014
Kevin McGillivray is a teacher and web developer from Wisconsin. He writes about creativity, mindfulness, code, and tea. He tweets and tumbles.