If you have never done this really useful little test with you team, then I urge you to. It may throw up some telling answers. The test is to ask members of your design team to vote as to who they think is the most important person in the design process that they are currently engaged in. If the answer is anything other than the user, then use it as a guide for your conversations and future development of UX in your organisation.
On the other hand ask yourself if you have yet fallen into one of the following tracks which might mean that you aren’t really doing UX.
Agonising over process and approach
Here, you aren’t solving customer problems! If you are doing this then you are looking to fix internal problems to prove how things should be done differently which alludes to a better UX; trying to be fast isn’t necessarily any faster!
Whether you think of Design-thinking as the only a method, or design sprints as the only approach. What creates impact in one organisation might not mean that it is yet proper or right in another. Each organisation is at a different level of maturity, ability to discover or indeed deliver. If you are more concerned with trying implement these, you are trying forcing a process to work rather solving users problems; therefore you aren’t focusing on or representing the user in your conversations.
You are trying to find ways to beat internal problems. I’d recommend taking a step back to understand your internal dynamics. After all, it’s fine knowing of them, and communicating how they should work but it’s another thing summoning the effort to force them to work. Someone in the near future will develop, evolve or verbalise something else, may be some of us have already been doing a similar thing, but is the motivation here only to stay relevant?
Take the essences of these processes and apply this thinking in your approach. When you have started to demonstrate value internally by demonstrating the value of UX then start the discussions about experimenting with these processes.
Deciding which tools are best
If you are concerned about or spending a lot of time trying out different tools to create an amazing prototype then you aren’t doing UX. You want to become a developer! (This is not a bad thing, and some of my past colleagues who I have a lot of respect for, have! Go for it!). You are so obsessed with ‘controlling’ what you expect back that you have forgotten that there is a point where design stops and development begins.
Developers are fantastic at their jobs; they make things work more robustly that you could (unless you aspire to be a developer, in which case it is still true). If you are trying to use them as an extension of your design process, then you aren’t letting them do their job. Alternatively, you could be doing this to understand the limitations (or constraints) of what you designing for; I sincerely commend your commitment to succeed. But the act of coding has very little to solving user’s problems.
Learn to tell a story of the experience; show, don’t tell. (Besides, this is the corner stone of great movies). It doesn’t matter if you are creating a functioning prototype with Ruby on Rails, or Invision; you could have conveyed the same thing with a sharpie and post-its or even with a white board and a marker. Less is definitely sometimes more! How much time have you wasted building and refining that prototype when you could be solving the next problem whilst someone else delivers on the last one?
Tell the story, don’t try to do the coders job for them.
Curating or designing a pattern library
Creating and designing a pattern library is hard work; implementing and governing it is a job in itself. There is governance to think of. There is auditing to be done. Deciding what should be cut and what should be included. What effect will preferring one atom have on another. Designing the colours and graduations of components and atoms are exactly that.
The value of a pattern library is to make the job of articulating parts of a solution and communicating an understanding of that solution quickly and effectively so that it doesn’t continue to be repetitive; or worst contradict what you have designed in the last project. Ultimately it allows you to focus on the problems that the user is currently wrestling with.
So start small and grow it. The more time spent on deciding the basic constructs will mean that you are distracted from focusing on users’ pain points and designing their magic moments.
Blue-sky thinking
Blue sky thinking needs to die quietly. It’s not simply a case of pulling the sky closer. Blue sky thinking only serves to alienate stakeholders because they won’t or don’t understand the motivation being expressed. Stakeholders will be switched of to anything that will cost money to create without any discernible effort to qualify the expected value.
If you are doing this then you are designing for something which may not actually be achievable. Can you really supply your design cost effectively? Do you really know that you haven’t just blown the whole marketing budget for a continent?
I have heard recently of an organisation where the team had designed a solution that the business couldn’t deliver on. Arguably, the solution that was recommended or designed was simply too expensive to implement; then if it isn’t feasible, it isn’t achievable. If this was the case, it was not fit for purpose either.
The result was no one stopped to ask if their design could be delivered. Perhaps instead of going off and designing in isolation without checking for constraints may not have meant that those poor individuals became jobless. Where is the strategic design management on these kinds of project?
User Experience design is about empathy with your users. It should not be about ‘a way that things should be done and everything will be easier to solve’, in that I consider adaptability far more of a skill required for UX to really succeed. I have found it easier and more fruitful to work with others and collaborate rather than try to arbitrate over process, tools, patterns or being outwardly idealistic.
Frazer Cooper 