November 28, 2019
The Origin app that my team is responsible for is 1st place in the utilities category!
November 28, 2019
The Origin app that my team is responsible for is 1st place in the utilities category!
March 3, 2016
A design student recently asked me “What 3 skills are the top things to master in UX?”. It’s hard to limit an answer to just three, but this is how I replied…
In order to truly design something that’s going to be useful and meet the needs of a person, you really need to understand the problems you’re trying to solve for them, from their perspective. You need to do your research and try to get a feel for what it’s like to walk in their shoes for a while.
The first solution you come up with is rarely the best. It’s important to open yourself up to exploring new and left-of-field ideas. Collaboration with others is a key component to help with this, and don’t feel limited to just brainstorming with other UX designers either; you never know who might come up with the gem that turns into the killer solution.
My background’s in Industrial Design and I believe that the ability to understand 3-dimensional space and ergonomics really helps in terms of interaction design. It’s more than a series of individual, independent pages; it’s about understanding the bigger picture — how the information architecture, content, page structures, UI components and transitions all work together to deliver the whole experience.
Lastly (I’m cheating now — this is clearly a fourth!), I added that in relation to UX design for digital products, I think it’s really important to have an appreciation of basic UI principles such as visual hierarchy, grids and typography, as well as a some form of basic HTML/code understanding. I’m of the belief that it’s important to understand the medium you’re working with, even if you’re not writing the actual code. Much like a designer of furniture should understand the basic properties and mechanics of materials such as wood and steel.
February 3, 2013
This article originally appeared on the Thirst Studios blog.
We’ve always said that this web and user experience design lark is more than a job to us here at Thirst Studios, and while that might just sound like a load of marketing rhubarb, I can assure you it’s absolutely true.
Outside of our client work, we’re all always reading and sharing industry articles, and regularly attend industry conferences, meet-ups and events. We do this partly because we love it and want to keep abreast of the latest tools, techniques and technologies, and partly because we consider it part of our job to be able to pass this knowledge on to our clients and use what we learn to help produce better products for them.
Aside from consuming an enormous amount of related, industry content, we also love to try to do our bit and give back. We run a regular bi-monthly event - Melbourne Geek Night - which is an informal get-together for people who work in the web industry around Melbourne to catch-up, have a yarn, share ideas and talk about new techniques and technologies.
We also produce a weekly email newsletter, which is a regular round-up of up-to-date useful and interesting industry news and links. It’s been really well received and we’re had some lovely feedback from our subscribers. You can see the latest edition online here and subscribe, if you fancy, over here.
Lastly, we regularly share our thoughts, knowledge and experience through regular articles that we write, not only here on the blog, but for a number of online sources and magazines. We’ve been particularly productive over the last few months…
Firstly not only contributing-to but also conceiving, curating and building UXmas - an advent calendar for UX professionals - along with the guys from UX Mastery. Both of our Ben’s wrote articles for UXmas; Ben Rowe contributed a brilliant article entitled The 4 H’s Of Writing Error Messages (which we were delighted to see was also picked-up and re-published by the guys behind Treehouse) and I wrote (U)X-Factor.
I’ve also recently started writing for UX Mastery, a brilliant online resource providing helpful, educational resources for aspiring user experience designers. I’m planning to impart my user experience design skills and knowledge through regular articles, starting with the first - How To Estimate A UX Project - which was also re-published by UX Australia in their email newsletter.
So are you in the enviable position where you get to do what you love for a living? If not, why not? At Thirst we’re all nerds who love nothing better then getting our hands dirty, both in and out of ‘work time’ on the things we are passionate about. Feel free to use the comments below to let us know what you guys are doing outside your working hours on things that you love.
January 29, 2013
One of the most difficult things to get right, even for more experienced UX designers, is correctly estimating a UX project.
Whether you’re a freelance designer who needs to give a quote to a client for a job, or an in-house designer preparing estimates for your project manager, estimating is always fraught with assumptions, what-ifs and unknowns. In this post I’ll list a few different approaches you can use to estimate your next UX project. I’ll focus on estimating client-facing work, as that’s where most of my experience lies, but many of the principles translate to internal projects as well.
Before we get into the detail of how to estimate, we should first take a moment to consider why getting it right is so important. No-one likes estimating projects—it’s difficult and not as much fun as doing the work itself. However, without an accurate estimate it’s impossible to know how much to charge your client for the work.
I’m assuming that UX design is your business, and not just a hobby, which means that generating an income from your work is an integral part of the gig. You, like many people might feel uncomfortable talking about money, but without it you can’t make a living from your work and keep the business running. It’s important you get comfortable talking about money and charging for UX work, because without this skill, you risk not staying in business (and doing what you love) for very long.
Unlike a physical product, for which the break-even value can be accurately calculated based on the sum of the parts and manufacturing costs, design work is much harder to price. You are selling yourself, your skills and experience—how do you put a price on that?
Typically, service industry work is charged in hourly blocks, with a cost per hour to perform that work based on the practitioner’s ability, skills and experience to perform that work. UX design is no different; whichever method you use to estimate and charge for the work (which we’ll get into in a minute), it will most likely be based upon an hourly rate.
Working out your hourly rate is key to the financial side of estimating, and it’s important that you charge accurately for the quality of your work. There aren’t any formally set rates documented anywhere for UX work, but you can get an idea of what your rate should be by:
talking with peers in the industry, and reviewing the results of surveys such as this one. If you’re struggling with determining your hourly rate, you may want to check out The Principles of Successful Freelancing, by Miles Burke. Miles is a very experienced web designer, and his book details a comprehensive process for determining an hourly rate based on your expenses, target annual salary, expected utilisation rate, and more.
Whatever number you settle on, be sure not to undervalue yourself! Charging too low or underestimating the amount of time to do a job can lead to resentment from both parties, and the quality of the solution you deliver may suffer.
There are typically three methods you can take when giving your client a quote for UX and design work:
The cost for each is based on the same hourly rate, and the process of estimating is the same. There are, however, subtle differences between these methods, and each has their advantages and disadvantages.
Fixed price, as the name suggests, means providing the client with a flat fee for the work. This is great for the client—they understand upfront what they’ll need to pay, and there will be no surprises. However, this approach places all of the risk with you, the designer. If the project runs over time on a fixed price job, you may have to wear the extra cost (depending on your contract).
Due to the risk involved, I would recommended that you be very comfortable with the full scope of work before agreeing to a fixed price schedule. Ensure you watch for scope-creep while the project progresses, and be sure that your contract leaves no room for ambiguity.
Many design firms add a percentage of “padding” hours to fixed price estimates. This allows them to weather any unforeseen scope and reduces the risk.
Charging an hourly rate—also known as time and materials is the fairest, most accurate method, since you simply track the time it takes to do the work and charge for that time at the end of the project (or at agreed milestones).
While this is great for the designer, the client harbours all of the risk in this situation; if the project overruns due to underestimating or changes in scope, the clock keeps running. It is typically rare for clients to agree to pay by time and materials on large projects due to the risk, but it’s quite common for much smaller gigs.
A ballpark figure + hourly rate is a combination of the previous two methods. In this instance, the designer provides the client with a fixed (ballpark) cost based on their estimations prior to starting the project, but with the understanding that if the project overruns they will continue to charge, tracking the additional hours.
This is a good solution for projects where the full scope isn’t known at commencement and the client doesn’t want to invest time in preparing a detailed brief.
Estimate how long it will take to complete
Now that you’ve worked out your hourly rate, you just need to calculate how many hours you think it will take to satisfactorily complete the work. Multiply that number by your hourly rate and you’ll have the estimate. Simple!
The big question of course, is exactly how to calculate the number of hours it will take to complete the work …
This is where I break it to you—there is no secret formula and even the most senior, experienced UXer hasn’t worked it out to an exact science. To a certain degree, we’re all making a best guess. There are however, a few tips and techniques you can employ to help you make it an informed guess and get as close as possible.
Have a defined process (and know it inside-out). If you already know how to undertake a UX project and are confident with the various techniques you can employ to get it done, then you’ll probably follow a similar process each time. A key factor in helping to accurately estimate a UX design project is having a clearly defined process, and knowing the usual series of tasks and techniques that you commonly follow on projects.
Once you have a good handle on your process, you’ll be much better placed to predict how long each task will take, and therefore what you should charge for each stage. Obviously each job and its specific requirements are going to be unique, and the number and complexity of techniques employed, deliverables and depth of planning may well be proportional to the project’s complexity. However, if you know your process well, it will help you plan and scale each estimate accordingly.
Break it into pieces. Just as the prospect of undertaking a large UX project can seem daunting at first, so too can the thought of accurately estimating how long it will take to complete one. Just as you would approach the project in smaller, more manageable pieces to complete, the best way to estimate how long a UX project will take to complete is to break the approach you plan to follow into small, achievable pieces, listing step-by-step the process you plan to follow for each particular job. The more granular you can get, the better.
We do this for every project estimate we put together at Thirst Studios. We usually start with a simple scribble on a piece of paper that follows a fairly standard UX design process, and then become more granular and develop the list of tasks required to achieve the specific requirements established for each unique project.
Record and review data from past projects. Nobody likes filling out their timesheet, but the only way to know if the project you estimated was accurate is to complete the project and record how long it took to finish each task. The more projects you finish, the more data you can gather to inform future estimates.
Ask ’em their budget. While it might be difficult to bring up the subject of money, you should always ask the client what their budget is. If you know what they’re expecting to spend you can easily work out the available time afforded to you and work back from there to define an approach that fits. This figure will help you determine what you’ll have time to cover, and what is out of scope.
Trust your intuition. Like anything you do, practice makes perfect—while it may not be particularly scientific in all cases, after a few projects you’ll start to get a feel for how long each type of project should take and how much it should cost. There’s a lot to be said for this intuition that experience provides, coupled with your sense for what you think the client is expecting in terms of scope.
What if I don’t have enough info to accurately quote?
There are occasions when you’ll be asked to quote for a project that you simply don’t have enough information about in order to accurately estimate: perhaps the full scope is not yet known, there’s no accurate project brief or the project relies on a third-party that haven’t delivered their work yet.
In these cases, the best approach is to charge for the work on an hourly rate basis rather than providing a fixed cost. If the client requires a fixed estimate however, I’d suggest you are very cautious about taking the job on, as providing a fixed-price quote without knowing the full scope of work poses a large amount of risk to you, the designer.
We have been known to undertake a separate, scoping project in these instances, to help the client define the project scope and develop a brief and set of requirements against which we could then accurately quote. This situation is ideal, but not always something a client is keen to invest in.
Failing that, one of the most difficult skills to acquire as a business owner is learning when to say no to a project. If you just can’t reach agreement with a client over pricing, don’t be afraid to politely decline being involved. It may be a sign that you need some more experience before you’re ready to tackle a project of that size; or it may be that the client is troublesome to deal with—and will continue to be so. Either way, you’re better off not taking the project on. The cost and effort required to save a project for a client who is unhappy with the solution you’ve delivered could be far more expensive than the potential revenue you’d be passing up by not being involved in the first place.
Unfortunately, there is no secret formula to estimating UX projects. It’s one of the most difficult things to get right, and even the most experienced UX designers will tell you they still haven’t got it worked out yet.
However, if you know your design process and the various UX tools and techniques at your disposal intimately, you trust in the value of your work, you employ the techniques listed here and you ensure you charge appropriately and fairly, you’re as well prepared as you can be to estimate the time and effort required to successfully complete a UX design project.
January 10, 2013
I can’t remember who first wrote this, but I think it’s a great idea.
October 25, 2012
October 12, 2012
I’ve never been to Brooklyn Beta but I’d love to go. It’s a 3-day web conference that runs in October each year and hosts talks from some of the best speakers in our industry.
Here’s how they describe it on their website:
Brooklyn Beta is a small, friendly web conference aimed at the work hard and be nice to people crowd. Once a year, we welcome some of the friendliest web designers, developers, and entrepreneurs to Brooklyn, and we invite speakers to highlight meaningful problems that need our help.
This post isn’t about the conference though. Its about the name badges.
Like most conferences, the organisers provide name badges for the speakers and attendees to wear, often including a job title and brief blurb about that person and their work. The guys behind Brooklyn Beta went one step further this year though, as it seems they contacted the speakers’ mothers for little personal insights for their bios. Take a look at the photos below of Simon Collison’s and Cameron Moll’s for examples.
A lovely, personal, human touch that goes beyond the usual, formal work-centric stuff.
July 24, 2012
July 11, 2012
Delighted to have been invited to judge the 2012 Aus Web Awards - http://bit.ly/ac8ce3
Check out the judging process - http://bit.ly/piEkAa
June 29, 2012
Over the course of my working career thus far I’ve had the great privilege of working with a number of large corporate organisations both here in Australia and in the UK. One thing I’ve found common to most (and always puzzling) is that most seem to force their staff to use IE6 as the organisation’s only ‘approved’ web browser.
It seems a lot of IT departments lock-down their staff’s ability to download and install new software, including web browsers, because it’s considered a security risk. That’s fair enough, but what I could never quite understand was why the love for IE6? It’s now over ten years old, is no longer supported by Microsoft and is much less secure than other, more recent browsers. For IT departments so concerned with security that they’re willing to lock everything down, doesn’t it make sense that they’d want to roll out company-wide upgrades to the latest, most secure version of Internet Explorer each time one is released?
For years I’ve assumed this was simply one of the great mysteries of the corporate world. Someone somewhere clearly knew more than me and I should probably stop worrying about it. I’ve just accepted that working on web products for large corporates just means putting aside new techniques, technologies and advancements that the newer, more developed browsers will accommodate. It essentially means everything we as professional web folk have learnt and developed since 2001 would have to be set aside for smaller, non-corporate clients and startup apps. It’s sad and a little nonsensical as a responsible web developer to be putting products together that have been designed specifically for eleven-year-old near-obsolete technology, but I figure it’s just one of those inexplicable nuances of life in large, corporate organisations.
It’s only after hearing something said at a recent web event that I finally discovered the reason for the proliferation of IE6 within the corporate IT world. After all this time! It’s not security (an argument which never seemed to make sense anyway) nor even grumpy, ‘jobsworth’ IT managers (that one never made sense to me either - surely IT geeks would be first in line for a browser upgrade?). It’s not really even IE6 that’s to blame really.
It seems that in the ten years since IE6 was released and adopted as the browser of choice back in 2001, hundreds and thousands of departments, within millions of corporate organisations have been squirrelling away, commissioning their own bespoke software to tackle all manner of tasks and problems, each unique and many developed to run in a web browser. As more and more of these little systems and apps have been developed, the harder and harder it’s become for the IT departments to upgrade, fearing that if they do - the products upon which so many of their staff are reliant might break. It seems they’ve got themselves at the point now that they’re so far down this path that there’s simply no turning back. If they upgrade to a newer browser it could cost millions (billions?) in re-development to fix everything, yet the longer they leave it they’re tying themselves more and more tightly to IE6. They’re damned if they do and damned if they don’t.
And this is where Mad Max comes in…
As soon as I heard about this situation it reminded me of the last scene in Mad Max. The bit where he cuffs a guys’ ankle to a car that’s about to blow up, gives him a saw and says:
The chain in those handcuffs is high-tensile steel. It’d take you ten minutes to hack through it with this. Now, if you’re lucky… you could hack through your ankle in five minutes. Go.
Anyway, back to IE6 and the corporates…
It’s a tricky conundrum with no simple answer, which is why the problem continues to exist, I suppose. But surely it’s time to act. Why not run with a newer browser like Chrome or Firefox for most tasks and instruct staff to use IE6 just for legacy apps?
Then again, what do I know?