Philosophy

15 years in product based environments has taught me that there is more to Product & Service Design than acronyms, buzzwords & the latest tool fads. In my experience, it is not the actual design tasks which are particularly difficult, but the contextual challenges around the process.

 

Some of these challenges include navigating organisational dynamics such as managing stakeholders with conflicting views, negotiating resource pressures such as tech & budget, speed to market urgencies, juggling features & priorities, & maintaining a consistent UX for the end user with an agile & responsive product vision influenced by changing market factors.

 

The case studies I have chosen to display here illustrate some of those challenges. You can also find a gallery of artefacts illustrating steps of my design process here.

 

See below for info on the tools & techniques I use.

 

OK that’s your philosophy, but what’s your approach?

My design approach generally tends to focus on linking the user experience to defined business goals and clear business logic, to deliver measurable results. My experience is in designing within truly iterative, lean & agile product development environments, ranging from startups, to large enterprises, ensuring business logic, commercial objectives & optimisation of conversion sit at the core of excellence for the customer experience. Having a technical background enables me to work closely with technical teams to specify and implement designs.

“Many ideas grow better when transplanted into another mind than the one where they sprang up.”

Oliver Wendell Holmes

I have a huge appreciation for the benefits of working with teams & colleagues as I believe collaboration is not only the fastest way to improve a concept, but also the fastest way to expedite a skillset. Protectionism of ideas is an ugly visitor to the world of product development & as we are all human, it is not something to hush under the table, but to review for in each designers’ own practice & out & identify at regular intervals.

Why design is not an art…or an ego…

One of the frequent complaints heard in design teams in organisations is that everybody wants to be a designer. In my view, instead of thinking of design as a power or territorial struggle, design has the potential to harness the innate excitement & motivation that comes from the opportunities for design from across the organisation, & to include all teams involved in the product development – making them feel more stake & buy-in in product development. In my opinion it is great to be passionate about design, however when working in organisations, it is better to leave the berets at the door & come with a collaborative approach to team work.

What’s an “Enlightened” past start-up founder?

I say “enlightened” because being in a statup & being responsible for the evolution of a product from beginning to end, including its reception into a new audience, has afforded me a much wider perspective on the role Service and UX Design fits into successful business.

My experience has afforded me time to reflect on my own design practice, & understand design from other stakeholders’ perspectives. Coupled with an environment dependent on lean & agile solutions has resulted in a much more flexible approach. To me design is not an art, rather a tool to facilitate consumer needs as opportunities for the business.

What tools do you use?

This is often one of the first questions I am asked. In short, I use whatever tools are right for the job & appropriate for the working environment. In my experience flexibility is key. Various tools are great buzzwords at the time, but they change so quickly, that in my view a good designer needs to be able to pick up new ones as they become available. Most design tools can quickly interchanged as they all work pretty much on the same principles.

As a designer in a product environment, I also need to be able to work conscientiously with my fellow colleagues & teams. If it suits specific teams to work with a certain tool, I have the flexibility to pick up that tool on spec.

See the catalogue on the quick view gallery page for some examples of the design material I work with and create through the process.

What is your work history?

You can find a summary of my work history here, or email me to request a full copy.

I take the confidentiality requests & contracts of clients seriously. Therefore there are some parts of my CV which I have not included in my case studies. Any insights I have shown from past projects are either purposely obscured or are already in the public domain.

What’s a full stack designer?

Where it is becoming increasingly frequent to segment designers into UX Designers, Service Designers, User Researchers, UI Designers & Usability Specialists, the term full stack designer is becoming more popular in use to describe a designer who has the skillset & hands on experience of the full range of design tasks necessary to take a product/offering from early stage concept through to execution. This includes user research (which is essential customer discovery) through brainstorming sessions, KPI business modelling, low-fi & hi-fi wireframe designs, to prototyping, user testing, iteration, build & testing.

 

It has been very exciting to witness & be a part of the development of the Product Design, UCD & UX domain over the past 15 years from its nascence from Jakob Nielson’s hypothesis on usability & user centred design, through the pervasiveness of wireframing, to the identification of the whole process as Product, Service & User Experience Design. I have been very lucky to have had the experience of establishing the design process in 3 organisations which has meant that I have never been holed into 1 particular skillset. I have always worked in progressive organisations & have particularly chosen projects within those organisations to expand my skillset.

I want to see more real-life samples of your work & process?

 

Sure you can! Take a look at the gallery here.

Again, I take the confidentiality requests & contracts of clients seriously. Therefore there are some parts of my previous work which I have not included in my case studies. Any insights I have shown from past projects are either purposely obscured or are already in the public domain.