The longer I do this job, the more I think that there are certain qualities, or attitudes that can make a real difference to ones ability to get better designs implemented, and generally enjoy the job more. Here’s my hopefully controversial list of qualities that will help you really rock.
Focus on trying to understand and empathize with the people you work with…they are smart people and do difficult jobs. Respect will come easy after that.
With respect and understanding comes trust… and if you really want to design something great the first thing you need is the trust of the people you work with and respect from them.
Moving from design dictator to design facilitator is a shift towards true collaboration. Design within a multidisciplinary team (is there any other type of team?) requires a shared vision and if you really want things to happen then sharing decision making and taking people on a journey towards an agreed solution is a great place to start.
Learn to move from “dictating” the UX design to “facilitating” the UX design… and watch how people really pick up your design and run with it.
I think its essential to trust that people are doing their best, and that if they say “that’s to hard”, or “we should rethink this” then trusting that its coming from a good place will, if nothing else, help you approach the conversation about why its hard in the right way.
Investing trust in the business is also essential, questioning every business decision they make is not exactly going to help – so trust that these guys are actually thinking about their jobs and that their priority decision are considered. This doesn’t mean you can attempt to better understand where they are coming from , but again, if nothing else trust will help you approach the conversation in the right way.
Dive deep into the data
This may seem like a strange one to add, but as a UX designer I think one of the most important things is to understand the underlying foundation of what “can” make up your design. In the end I think applications are very simple, all you need to understand is that there is data at one end (e.g. the XML returned in some API) and there is your application interface at the other end. Its rare that you can make fundamental changes to the underlying data, but you have almost complete freedom (in a new application) in deciding what to do with that data. The page flows, the presentation and passing of that data is in your hands.
Diving deep into the data will also help you understand what your devs are doing, it’s a shared place that you can build conversations around – and it also will often give you a deeper understanding of the wider system (e.g. how the data got into the system via a sales consultant and what was driving them as they were creating this content).
Once you understand the data structure, then both dev and the business will give you more time because they know you understand the underlying issues that they are dealing with.
So don’t be scared – go and have a look at that XML and understand the basic request and response mechanisms that drive data to your application.
Take the initiative
Taking the initiative early is the best way to maneuver yourself into a position where you can have a real impact on the project. At the beginning of any project there can be a general lack of vision around how its all going to work… in fact there is often confusion about what’s even required. This void is debilitating for everyone and the only person who really has the ability to push the project forward is you (UX). Its imperative that you take the initiative in this early phase and work as hard as you can to clarify a vision and direction – this is not something you do in isolation – it’s a journey you need to take everyone on. Once you have built trust and have the decision making initiative everything becomes easy and fun.
Drop your ego
Care enough not to care. Be flexible, and accept that you may not always be right. Dropping you ego is the first thing you need to do if you want to be collaborative and inclusive in design decision making. Trust me – you will get better results.
Focus on high fidelity, and making the abstract concrete
While you may have the entire design in your head, its likely no body else does. Focus on describing the design vision in high fidelity, and on making the experience as easy to understand as possible. I always develop high fidelity blueprints which I place on the walls around the devs. I do everything I can to make understanding the UX design as simple as possible. Forget abstract site maps and complex page flows that reference other documents – simply past up every page template in the application on a wall, and show how these all link together. The aim is not to show every state possible – its to get a high level understanding of how the entire site works. You will be amazed how well people respond to this method. And if you thinking that your application is to difficult or complex to do it – well that’s bullshit. Its up to you to figure out how to communicate this – focus on expressing the typical straight line page flows if approaching it from a template point of view is to hard. If you think its to hard to design or document this then imagine how hard it is for the devs to build it. In the end Focus on producing a high fidelity definition of what’s to be built, and on making the abstract concrete. You may find yourself collaborating with the devs to make the design more consistent, efficient and simple – and in my experience this is definitely a good thing and most often these changes make for a better UX for the users.
Prototype and test
You may be a genius – but thinking hard about a design can’t really give you the feel… best way to get a good feel for the design is to build a proto early and test it. Sometime I think the real value of user testing is in simply the act of building the proto and getting the time to watch people use it over a few days. Nothing gives you a better feel for it.
As an aside a proto is also a brilliant tool for the business to communicate what you’re intending to build… and a great tool for the devs to understand what you’re thinking.
Choose your battles wisely
Remember what your trying to achieve… a great UX for a majority of the users. At various points throughout the build process there will be times when you need to either fight for something, or take the path of least resistance and accept a slightly comprised UX for the sake of simplicity and protection of the final delivery date. These decisions are not about ego, or you getting what you want. Its during these moments that you can either gain the respect of your collogues, or start heading down the dangerous path of being sidelined because you don’t seem to understand the bigger picture. Its terrible to say this, but its not always about the user…. Opps – did I just say that?… or perhaps more precisely it is all about the user and sometimes taking a pragmatic approach to crafting the overall best result for the user is best served by releasing a solid app on time, to budget and then focusing on iterating the application in future (something that is more possible when you get the trust and respects of the people who actually fund future projects)
Your ability to manage relationships and conflicting agendas during the project will directly reflect on your future chances to drive continuous improvement of the application post delivery. So choose your battles wisely and remember it’s the war your trying to win.
And don’t forget the users
Most of this advice is about how to work better in your teams. I’m assuming your already a great UI / UX designer and understand the importance of focusing on the understanding the users needs and goals, the likely tasks and scenarios of usage that support these, and all the other basic UCD type principals that inform what you should be doing.