How They Did It: Haraldur "Halli" Thorleifsson
We'd make a safe bet that you've seen Haraldur "Halli" Thorleifsson's work in the wild. With major projects under his belt such as the Google+ information page, Google Drive information page, as well as working for Square, Pinterest, Microsoft and other high profile clients, Halli's work is everywhere. However, today we are focusing on his beautiful portfolio site, which you can see at haraldurthorleifsson.com.
We had the chance to talk with Halli about how he approaches design, and we talked specifically about how he approached the project of putting his own work out there. Here's what he had to say.
Tuts+: When you were approaching the problem of building out your own portfolio, what were your design imperatives and objectives?
Halli: First of all, it was for myself. As you know, usually you don't have full control over projects you're working on [in the contracting world] — they may have commercial or business reasons for doing something you would prefer to do in a different way. I think most designers are proud of their work and they want to show it off in the best possible light, so that's what I was thinking in the beginning — mainly for myself, and obviously once I had something I was comfortable showing, I could put that up to attract more clients.
I've been doing this for a long time, so I've had multiple portfolios in the past, they were always basically endless rows of screenshots, cause that's the easiest thing to do. That's kind of boring though, so I wanted to break it up, put those screenshots into some context, put design elements around them, and make these case studies their own thing.
But even though it started as a project for me it quickly became about other things as well. If you have a nice portfolio, you can push it to awards sites, and assuming you win a few, that will get you a lot of traffic and hopefully somewhere in that traffic there are some new interesting clients.
I also use Dribbble a lot, and I saw the portfolio and my Dribbble account as being connected. I wanted to drive traffic from my Dribbble to my portfolio, and from my portfolio to my Dribbble so there's sort of a self-feeding "tapeworm". If we did it right, we would get a lot of traffic to the site, and leverage that to gain more Dribbble followers. It's not just a vanity thing or a quest for a following, Dribbble is becoming such an important platform for getting new client work. The more followers you have, the higher up you are on search results on Dribbble itself.
Tuts+: So it's almost like SEO for Dribbble?
Halli: Yeah, that was one of the main reasons I decided to have the Dribbble index at the bottom. I wanted as many people as came to the site (we got about 100,000 in the first month) as possible to follow me on Dribbble.
Tuts+: So, have you seen an increase in that followership?
Halli: Yeah, I saw about 3,000 followers out of this one launch.
Tuts+: That's fantastic! So, you've mentioned you've had screenshots in the past on your site, which is still a primary element of this design iteration. How have you found the place for these to sit? Each of these portfolio pieces is its own beast — specific elements for each portfolio entry with their own interactive characteristics. They are sort of "meta projects", or projects about projects. How have you made the site support these varied screenshots all in one place, while retaining cohesiveness throughout the design?
Halli: The problem with using a website as a way to show website work is — well, you have a person come to the site, and you have a frame for the site you're trying to show, and how do you show it in the browser? By showing them another browser? It gets so boring. Some projects are harder than others. For instance, the Google+ project was all layout work, and there's not really a lot I could do there, so I had to try to stack them in some interesting way, but it doesn't really lend itself well to something like that. On the other end, something like Santa Tracker or More Than a Map is a lot different because there's so many visual elements outside of what you might find in a standard website and since those were both full screen experiences, all the screenshots have the same aspect ration. Google+ on the other end is a lot of really long pages, it's not easy to show that.
In the beginning, I didn't want to have a template, because I knew the projects would be different — there would be no way for me to design a template that would fit all of them. I also wanted the style for each project to take over the page. Most of these are really flat, or aimed towards flat stuff, but I wanted to be able to let a project that's not flat fit in the site. That's why the site doesn't have any controls other than the top bar, and I can change the color of that. The site is pretty much a blank canvas when I start to show a project. And I think it must be pointed out that my developer is so amazing that he just accepts that he won't be able to reuse any elements. *(laughs)*
Tuts+: That's another interesting aspect of this project. You told us before the interview that you don't code, which can be a good constraint. This is a hot topic in the design world. People like Chris Coyier have said positive things about letting designers have full creativity over their work, to design without having to translate that to the browser in tandem with their design process, and then take that to the developer as a challenge. Have you intentionally kept yourself away from code, or has it been more of a personal choice to not learn it?
Halli: I think almost everybody can learn anything, so I don't think it's that so much. For me or anybody to become really good at something, they have to really focus on it for a long long time. And it's just not where I want to focus my time. I could code a basic super-simple site, but it would take me a long time and it would be really poorly done — there are people out there that are a lot better at it than I am, and for me to catch up, I'd have to do that full-time. People talk about these "unicorns" (designer-developer hybrids that are great at both)… and there are frankly not a lot of them. When you ask for a list you always get the same names. When you have a designer that's also a developer, they usually are thinking "how can I design this so that it's easy for me to code", where as I don't have to think about that, so I can decide what I want to design. Pretty much anything at this point in time is translatable to code. That wasn't the case when I started fifteen years ago. Now, anything I can dream up, someone can code.
The problem I have with the "designers should code" argument is that there's also so many other things they really should be doing. They should know about marketing, they should understand business, copywriting, storytelling — there's so many things they have to keep in mind. I wouldn't put code at the second-priority spot on the list of things to learn for a designer. But having said all that, I don't think there's really a rule for "this is what a designer should be" — if people want to design and code then more power to them, it's just not for me.
Tuts+: One of the main arguments for designers needing to learn code is that it helps designers understand responsive design and device agnosticism. How does the problem of cross-device compatibility affect the way you think about a design approach? For instance, with your site, we sized it down to 220px wide, and it looked great, but it also looks fantastic at 2000px wide. How do you do that with a site like the Google+ information landing page when you're designing statically?
Halli: I think its experience, mostly. I look at websites all day long and have for a very long time. Now, after responsive design came on the scene, any time I come to a site, I resize it to see if it responds. I try to see how they move the elements — not necessarily how they are technically doing it in code, because someone else can figure that out for me.
It seems to me that problems with designing totally in the browser is that the designs tend to look the same but maybe I'm just too old, been doing this for too long. Maybe the new designers will figure this out better than I have.
If I'm working with a really good developer like James Dickie, who coded my site, if I have an idea of how things will look down to mobile, and I have an idea of where the breakpoints are, and how they should function, usually what I do is hand him the desktop portion. He puts that into the grid, and we see what happens. We just iterate from there. I don't design all of the breakpoints any more. I know that if the design is a certain way, so we don't have a lot of stacked elements, it will probably size down gracefully. There are always problem areas, but usually its best to fix those problems directly at their breakpoint. Sometimes it amazes me how well it works to put a design in the grid. So, maybe you could argue that I do design in the browser after all...
Tuts+: So it's almost like an intuition at some level — you've learned that this is the way people interact with browsers, this is the way browsers work, so let's see if we can, for instance, keep this more vertically laid out.
Halli: That's one of the main things I do — I try to almost always put things vertically. Not necessarily because of responsiveness, but because I want the user to focus on one thing at a time — I don't want them to see multiple things. I want them to scroll down the page, experience a progression, some kind of story that I'm trying to tell, hitting the emotional things you want to hit. If you're trying to sell something, you end up at the end of the story after hitting these points, and there's a buy button there.
That approach is obviously a lot easier with communication design. It's not as easy in product design, where there's usually a lot more actions you want to put in front of users, which is more challenging. Which is one of the reasons none of these really big product sites are responsive all the way down.
To go back to your question about audience — the audience for this was really agencies or clients that will have a big monitor, usually. They will have the expensive stuff, and I wanted it to look really good on a 27" display. It needs to look really great on a huge display, so we when we need to, we have huge images at the top of some of these things — like 2500px wide — and you know, I didn't have to think a lot about constraints like bandwidth, because usually that's not a constraint for that audience.
In terms of the responsiveness, my developer deserves a lot of the credit there. I initially thought making this site responsive would just be way too much work I told him in the beginning that he shouldn't worry about that at all, but he insisted. So, he should actually get most of the credit.
Tuts+: And that's also something we want to talk about here — how much value do you put on how well you can communicate with your developer? You've mentioned him a few times, and it seems that that teamwork is very important to your process.
Halli: There's no website without a designer, and there's no website without a developer. It might be the same person, and it might not be well designed or well developed, but there's no way to have a site without both of those elements. Like I said previously, I think most people can really only be great at one of these things. Having a developer that can take something that I design and code it is extremely important, so having a good relationship with that developer is also really important. I've been working with James for a while, and I pitch him for every project I work on.
The most important thing is usually the communication. If you are able to talk to someone and they respond to your notes and agree that moving that one thing 1px to the left is totally worth it, that's valuable. On this project, I would change my mind, and James would go back and forth with me, suggesting ways of doing things, moving things around, etc. Without that process, it wouldn't be half as good. So, I think it's extremely important to have that involved developer. A lot of times I will hand off a design, and I don't even get told when it launches. There's no communication in the process, and as you can imagine that doesn't lead to the best results.
Tuts+: Yeah — you want open lines of communication as much as possible.
Halli: You want to be able to disagree, and have someone who can tell you that there is a better approach. If the developer has a good eye for design, he will make everything better. Some of the best feedback I get is from developers. As long as it's coming from the place that they want to great work as opposed to doing the easiest thing, then I listen.
Tuts+: Yeah, it seems that a lot of developers have to weigh this constantly — that the business value of the design request matches the amount of effort it takes to complete that request. How do you balance the seesaw between great work and great business value?
Halli: I always think that, in the end, they are the same thing. If I come to a website and it's ugly, then it's probably not going to sell me something. If I come to a website and it's beautiful but doesn't function, then it's also not going to sell me anything. I really like working with people that will go the extra mile (or few hundred miles) because they want something to be really good. I think that it's difficult to put a dollar value on it, but it's still worth it.
Tuts+: Completely agreed. We're going to shift to a sort of hot topic that's been thrown around all over the web that you alluded to earlier in the interview. You mentioned that the site has a flat aesthetic. There's a lot of critics in user experience and a lot of people who are for or against "flat" vehemently — there's a big war of design in this area. I'm sure that in fifteen years of working in design, you've experienced similar drama. Some people say about "flat" that it's genuine, that it steers the digital experience to be genuinely digital. What are your thoughts on this argument?
Halli: Well, I think that's a simplification. I think the reason for flat is complex. Responsive plays a part — if you have a flat surface, its really easy to scale it up or down. If you have a flat surface, it doesn't take up a lot of bandwidth. But its also just time consuming to design the old Apple-style icons — it took so much time.
So I think there's all sorts of different reasons and then people idealize some of these things after the fact. A lot of people treat this like a religion, saying things like "that's not flat enough", as if the ultimate objective is to have no shadows, no gradient anywhere — as if the best design is completely flat, which I totally disagree with.
There's a problem when you get a trend where everybody goes all in — everything is now starting to look the same. How do you differentiate, or make anything memorable?
I do think flat, or at least flatter than what we had, is great for a lot of things. But I still like gradients and drop shadows. They can be a lot subtler than they used to be. People are beginning to understand that a button doesn't have to look like a physical button. But it still needs to stand out, and it needs to look like you can press it. I think "flatter" than what we collectively had before is good. I think totally flat doesn't serve any purpose. If it works, then it's fine for your project. We shouldn't make it an objective in itself. I've actually been in meetings where people would say "that's not flat enough" — there's not really any way to respond to that.
Tuts+: Absolutely. Design should be respected as a higher level thing than just simply deciding we want to go towards a flat aesthetic, so let's drive everything to flat. That's not achieving anything but the desire to be flat.
Halli: Yeah, to follow the trend. Unless you have a reason, like for instance, Google. I don't know if you remember, but Google used to be really ugly. One of the reasons was that they hired their first designer around seven years into the company, it was, and in many ways still is, a very developer driven company. But they also have so many independent divisions, unlike a company like Apple where there's a massive top-down design imperative. Google has these many departments that have a lot of freedom, so reigning all that in is a huge effort.
I think the design team at Google did an amazing job with that. I think they picked the flat style they have now partially because it could easily be explained. You could bring people in and scale that design, because you can set a style guide that could be easily followed while still maintaining a lot of the freedom you had before.
Tuts+: And it's awesome that you had a hand in that shift in Google's design. And that's a great reason to go flat. And you can see what you're talking about still in Google — with pieces like Analytics being totally different from something like Google+ or Gmail.
Halli: And also, with iOS 7, I don't think it's flat at all. There's a lot of depth, there's a lot of gradients. And btw, I really like iOS 7, there are a few rough edges but overall I think it's a great leap forward for Apple. It might not be that skeuomorphic anymore but it's not flat.
Tuts+: Yeah, it's a common misconception — similar to when someone says something is parallax when it's not actually parallax. The misconception is, if the buttons don't look like buttons anymore, if things are minimized to fewer colors, fewer borders — people will label it as "flat".
Halli: Yeah. One thing I like about flat is, you can have more elements. They don't compete with each other. If every button is really heavy, having a bunch of them on a page starts to look weird — the gravity of the page goes off. Flat will allow you to have a more complex UI and still not take too much visual space.
The UI of iOS 6 Find my Friends is a good example of this. The UI is in the way. It's so heavy that everything else falls back. It should be the opposite of that — the UI should be in the background, the experience and content should be in the forefront.
Tuts+: Absolutely. We're going to round this out with one more question about your portfolio, and this one is sort of a broad question. What challenges were the most difficult in this process? Everyone is their own worst critic, and its empirically difficult to build something for yourself, cause there's a sense that it's never going to be finished if you have the keys. For instance, you constrained yourself to the four projects at launch, and then pointed people to your Dribbble. Did you set a timeline or constraints to launch?
Halli: About a year ago, I started to redo my portfolio. I knew I wanted to have flexibility, I knew I wanted to really take my time, and I knew I didn't code. I actually started by building out the whole site entirely out of PNGs, text included. That way, I could put up a case study in my own time — I didn't have to depend on a developer. I could see it live for a while. I could take my time designing it between paying projects.
It was extremely simple, and it made some developers cringe, but it meant that I could really take time to think about those pieces. When we finally moved on, I knew those case studies were the ones I wanted to use. I wanted to show breadth, a few things I could do.
After we relaunched, the site was pretty much as it is now except the case studies were in a carousel. But that gave too much weight to the Dribbble feed, as its so much more visually complex than the case study links. So James suggested to break them out of the carousel, we did it and then I finally thought the site was done.
People sometimes ask me about the Dribbble grid, as I said earlier, one of the reasons was to drive traffic there and gain followers but I also wanted to be able to show new things easily. Some projects aren't big enough for a case study, but I still want to show them somehow. I also wanted that feeling of people coming in and saying, "okay, there's a lot of stuff here." so the Dribbble grid is a way to avoid being perceived as someone that only designs for Google.
Tuts+: And that's interesting, because it certainly outlines your work with Google most up front. Of course, that's the most visible to the world, so that decision makes sense from the perspective of trying to gain new clients. But then you look at your Dribbble, and it's a much wider array of work and style.
Halli: And it goes back to an earlier question — when I was starting to do my portfolio, and the case studies, I was reading an article. They did this experiment where they put a really great violinist, Joshua Bell, in a DC Metro station. He played like an hour or two, and made maybe $20. The next night, he played at a theater in Boston and sold out an auditorium at $100 a seat.
Whilst I was reading that I just remembered thinking, I have projects I really like. I have put them up on Dribbble, and they didn't take off at all. As a designer you should really know that context is everything but for whatever reason it just never clicked that it's exactly the same when you are showing off your own work.
People need help perceiving value. People may think something is valuable because it costs a lot, or in my case because it's put into some kind of context so that you can see that there's care put into it. I was thinking about Joshua Bell, the same guy playing the same piece in both places. Maybe the acoustics weren't the same, but there was something with the context that made one group of people in one situation understand the value of the work and another group of people in another situation value it completely differently, or more accurately, not value it at all.
My site took a lot of time and effort for me. So the question was, is it justifiable for me to put aside paying client work and focus on my own stuff? I finally decided that maybe it is important for people to see my work in the right context. And I can speak from experience after the fact and say that it was totally worth it. It helped me get bigger and better projects and it actually made me a better designer.
So I think everybody should do this — to showcase their work in the best possible light. If not for the world, then just for themselves.