thumbnails

About

I work hard. My interests include design, politics, tribes, culture, psychology and interventions. Mainly, how these cross over and how we should intervene, how we can design. More details on Linkedin

Design Process

In short, I like to understand the issue, challenge the problem, sketch solutions, test the designs, develop the design, release and do it all over again. And I'll essentially utilise any combination of that process depending on the context.

At the heart of everything I do is the person using or interacting with the product or service. Wherever I have worked I have brought that principle with me and even with a lot of experience now I think it even more important.

Designing applications for users in healthcare, development, sports and culture I've had the privilege of researching and learning how people work from all around the world, for different languages, for different perspectives and for different motivations. What I have noticed and what I have spent a lot of time understanding is human behaviour. I've coupled my applied learning with a strong understanding of psychology and culture, lenses which have helped me shape my understanding of the users of products and services I was designing. What are the contexts in which people work, why do they do certain things and what do they want from those actions?

I'm not an armchair designer, I prefer to get out and talk to people or look at evidence as a way of understanding and defining a problem. The understanding fuels the ideation, it enables less wasted time in meetings, increases chances of success and most importantly helps the user do what it is they need to do.

In IBM we spent a lot of time creating poster journey maps and task flows, hi-fi documentation and slide heavy decks articulating these ideas. Buy-in was a major factor in such a big and traditional organisation, but in a smaller more agile company I now err slightly more on the lean side when it comes to documentation. Communication is key, but in a smaller company that can be done a lot easier than at a larger org, thus the documentation can be emphemeral especially if you are releasing and learning continuously.

There are many topics I could cover here, but that's where a chat is probably better. If you want to chat give me a shout my email is byrne.saar@gmail.com.