From Designer to Product Owner: The pleasures and pains of being given control of the product vision
As the UX Design discipline has matured in the last few years, business people have started appreciating the value that our design thinking brings. This has created a growing trend of UX Designers taking on more business responsibility and moving in to Product Owner roles.
As a UXer, I see this as a very natural step in the evolution of our profession. The constant bane of my usability testing life has been UI issues caused by business decisions that are baked in to the value proposition of a product. Issues created by the design of a page element are easy to fix in comparison.
By taking on the Product Owner role, a UXer is able to move further up the decision making stream and have an input in to these business decisions. Here they can help shape the product strategy and avoid choices that negatively impact the user experience – rather than having to compensate for them later in design.
My simplified view of a UXer as Product Owner is that they would bring a different focus to the role. Rather than having someone focus on numbers and project management, you would have someone who is passionate about creating great experiences, as well as possessing the skills required to envision and design it.
The flip side of this is that the UXer as a Product Owner would most likely be weaker in the pragmatic business skills required for the role, such as budgeting and planning. However, with some support from the business these could be easily overcome.
On my latest project I was given this opportunity to take on a Product Owner role, owning and driving the product vision while building a new innovative product. Not unexpectedly, it wasn’t the entire UX utopian wonderland that I had imagined in my mind.
Here are some of challenges and lessons that I’ve taken away from having to put down my post-it notes and embrace spreadsheets.
What do I mean by a Product Owner
To start, let’s state a quick definition of a the Product Owner role in an Agile team:
Product Owner – The Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. http://en.wikipedia.org/wiki/Scrum_(development)
On a day-to-day basis this means that Devs are always talking with the Product Owner about the scope and requirements for stories. Then, once a story has been developed and tested, it is shown to the Product Owner before being deployed.
This means that the Product Owner is essentially the key stakeholder who sets the direction of the team, prioritises what they work on and signs-off what they deliver. This isn’t so much about authority as maintaining accountability to the product vision.
About the project
At this point I can’t actually share details of the product itself, however I can talk about the team and project setup. We assigned our own internal Product Owner as the client wasn’t able to spend much time with us in person on a day-to-day basis, nor did they have much experience building software. What they did have was a clear vision for the product. Therefore we needed someone within our small team to act as a Product Owner and be responsible for understanding and representing that vision. It made natural sense to assign a UXer to this role as we would normally include a UXer in to our teams to design and articulate the product experience, which requires an understanding of what the product vision is.
What was different for me as a UXer in this case was that I had to take control of guiding the strategic decisions of the product for myself, rather than just designing the interface and advising someone else.
Embracing the natural tension between a UX Designer & Tech Lead
What became a key dynamic of the project was the pairing of myself and the Tech Lead and the way we learnt to work together.
As a pair, the two of us we were responsible for leading the team and communicating with the clients, but both of us with a different focus – me on the vision/user experience and the Tech Lead on figuring out how to build something that combined a challenging suite of technologies.
On any project there is always a natural tension between Designers who want to build the perfect product that they can see in their mind and the Developers who have to find a way to practically build something out of code. This disconnect can easily turn it to friction if there isn’t collaboration (see Waterfall).
In a healthy team, where each person understands and appreciates the other’s priorities, embracing this tension fuels an ongoing negotiation and collaboration – which is required to build a great product. This is the basis for believing in the value of multi-disciplinary teams.
For myself personally in this context, it constantly forced me to think not just about what the ideal end state should be, but also about the smaller pragmatic steps required to get there. And if I didn’t, it would only be a matter of time before the Tech Lead pulled me back down to earth.
This wasn’t all just one-sided negotiation though. By articulating my ideas and the intent behind them we were usually able to find solutions that met both our needs, or just simply agree that a high-value feature was worth the high-cost it took to build.
Living between worlds – no longer a blue sky designer
This ongoing negotiation led to a subtle yet significant shift in my mindset.
As a UXer it’s your job to advocate for the user and get the best result for them. Of course this needs to be balanced with business needs and technical feasibility. However, as a designer I’ve still always tried to find ways to sneak in little extra bits of functionality – no matter how much Minimum Viable Product Kool-Aid I’ve drunk.
As a Product Owner I was acutely aware the full backlog of scope and how adding in anything extra came at a cost of pushing out other features. The clients had a clear vision of what the product should be (this was arguably their MVP) and this in itself was an ambitious piece of work.
It became a day-to-day priority to think about what is the least amount of work we can to do to get this product out the door. Whilst as a UXer I wanted to build the perfect product, the business needed to launch it sometime this year and the technology layer meant there was a lot of work just to get anything up and running.
At times it felt like I had the Designer devil on one shoulder and the Product Owner angel on the other – one trying to convince me to sneak in extra features whilst the other reminded me of the timelines and scope.
Designers love constraints. As a designer it became an interesting challenge to design for the most pared back version of the product I could figure out.
I stopped thinking about what is the dream state for this product, but instead, more pragmatically, how can we get this built? I became focused on what stories could be stripped out and deprioritised in the backlog, not on what other cool things the product could do.
I became acutely aware of this shift one Friday when I was sharing my work-in-progress with other ThoughtWorks UXers during a design studio session. Whilst the other designers were having fun exploring ideas in a lively session I was getting frustrated because everything they were coming up with was adding to, rather than removing scope.
One practical tool it did make me think about is that the next time I’m running a collaborative design sketching session, a great way of setting the design challenges we usually state as ‘How Might We…’ would be to ask both:
- What is the blue-sky version of this feature?
- What is the minimal version of this feature that will still meets the user need?
Living between worlds – not yet a pragmatist Project Manager
The part of the job that I didn’t choose to sign-up for as the Product Owner was the project management duties – coordinating resourcing, sequencing of events to get to the end goal, managing clients, etc. In a smaller team these duties naturally come with the role, as it’s hard to justify a dedicated Project Manager resource when it’s not a full-time workload.
This was not unexpected, nor a major problem. The challenge came from me not being a skilled or experienced PM by nature, particularly on non-design related activities. With some support and assistance from the team we were able to share the load and teach me new skills where appropriate.
The problem came from the amount of my time and focus it chipped away. It all meant less time that I was able to spend doing actual design tasks and communicating the vision.
Finding time for design
The biggest challenge I faced was carving off dedicated design time to perform my other part of my role, that of the UX Designer on the team.
Prioritising, analysing and reviewing stories with devs became an all-engrossing task on a daily basis. It was one of my most important tasks as it’s where I had real ability to shape the small details. In a team with 2-3 dev pairs, there were always stories needing to be analysed, reviewed, or just needing some informal input from the PO. As someone supporting the team I had to prioritise these. The last thing I wanted to do was become a bottleneck or discourage the devs from seeking my input.
This meant that I rarely found the dedicated time to do traditional UX work, such as prototyping and wireframing. In an Agile world it’s not very PC to say that I sometimes need to put on my headphones and block out the rest of the team, but sometimes it’s necessary to focus on a design task without distractions for a full afternoon so that you can get your head in the problem space. Tackling complex problems can be compared to going through the cycles required to get into deep REM sleep or just achieve flow.
Sometimes the content in a higher-fidelity wireframe or design mock is the best input for a dev to build from. They focus on coding the plumbing that makes the page work and not the exact layout and copy on page. A typical example of this is web-forms. I’m quite particular about the getting the language right on these for the user, whereas devs are usually focused on capturing the right data and storing it appropriately. Taking the time to wireframe out the flow and wordsmithing the content is a small upfront investment. It takes the guesswork out of the dev time and avoids revisions or accruing UX design debt – but it takes some dedicated time to create.
This kind of work also helps towards building and evolving a design wall, which creates a shared vision that is visible to everyone. I always had plenty of ideas in my head, but it’s easy to forget that everyone else in the team hasn’t had a chance to be part of all the conversions and whiteboarding sessions. I was the only one who had full view of the overall picture vision that I have in my head. Taking this time to capture it, get it out of my head and on to a wall is critical is the only way to effectively communicate it.
Feeding the devs – Designing based on a pull system
Agile UX involves designing just-in-time. This pull-based system is a different way of thinking for most designers.
I had to learn to be disciplined about focusing on the stories that were in the immediate backlog, not thinking about the full picture for the next 6-12 months. As much as I wanted to consider and design a solution that would support the entire feature set that we could ever build, it doesn’t help you use your precious design time to keep feeding the devs who are building the here and now.
The thing that I’ve learnt to do is to design for the stories that are coming in the next one or two months (or 2-3 iterations). Usually there is a common theme to what stories are coming up in that period. There is usually a manageable chunk of features that can be considered as a one design piece, so that you don’t have to revisit the design every story.
At the same time this allows for emergent design, where you are able to build, test and learn. Starting from a simple design and allowing the details to be built and refined as you learn more. This does mean that sometimes you need to circle back and change the parts of the interface that have already been built (find the time for this is another challenge in itself).
What this does mean is that you willingly take on UX design debt.
Accepting UX design debt
Sometimes you need to take on a little bit of debt to be able to purchase something.
As a Product Owner I had to learn to let go of control of every detail and accept some things that weren’t perfect in my mind. Otherwise we would never have been able to get anything done. Partly this was just about learning to be patient in seeing the product evolve. Partly is was it was about letting the team figure out some of the details for themselves, even if it wasn’t perfect from my designers point of view. It comes back to thinking about UX as a facilitator, not just a designer.
No product is perfect in it’s first version. Great products take time to mature. Even the sacrosanct iPod/iPhone took a couple of versions to truly hit its stride.
It’s all about the journey, not the destination
The biggest take-away for me about the experience is the shift in the focus from the destination to mapping out a path to get there.
As Designers we’re great at envisioning these utopian like product states where everything has clean smooth lines and plenty of white space. We can mock that up for you in no time. What we’re not so good at is thinking about the steps involved in creating that vision.
The Product Owner needs to find a way of guiding a team to develop a product from it’s current state, be that a rough idea or working software, to where it needs to go in the future. This requires patience and understanding the challenges that need to overcome along the way, particularly that of making it profitable/sustainable in the mean time or the destination changing.
None of the products that we put on a pedestal now started like that in their first version, whether it be the iPhone, Facebook or automobiles. They all started as something far simpler and have evolved over every iteration to what we know and love today.
As a Product Owner you have to start thinking more strategically about how you steer the product along the way. Having a better appreciation that this journey is taking place going to make me a better, more effective designer.
Calling all Brisbane based UXers
Come join the Brisbane User Experience & Interaction Design Group.
For User Experience & Interaction Design professionals who design interactive systems and products of all types: web, desktop, mobile, consumer electronics, digitally-enhanced environments and more. It’s a get-together to share ideas and learn in a social environment, and is typically made up of short presentations and entertaining discussions on trends, tools, tips and techniques that help Designers in their day to day design work.
This group is the latest version of the IxDA Brisbane group. As part of this technology refresh we the time has come for us to update this group’s name and migrate to the Meetup.com site.
I have also set up the Brisbane User Experience & Interaction Design Group LinkedIn group. I also encourage everyone to join that group so we can continue to increase our visibility and networks.
I look forward to continuing the conversation over on the Meetup group.
The UPA is dead, long live the UXPA!
Recently the UPA (Usability Professionals Association) announced that it is changing it’s name to the UXPA (User Experience Professionals Association).
You can see the announcement letter from the president here – An open letter to the User Experience Community
The UPA has long been criticised as being a relic of an old school mentality that ‘Usability’ is a something separate to of the broader UX design discipline. Largely this has just been because they haven’t wanted to change the name of a well cognised professional organisation. None the less this has still led to them being seen as outdated by other groups such as the IxDA (Interaction Design Association). Or in competition with HCI people.
This has also been part of the ongoing conversation about defining User Experience Design, what fits under this umbrella term, or that you can’t design an experience – just the interactions.
Is this change a sign of the UX discipline starting to mature, or just simply a cynical land grab from professional bodies? I’m curious to hear other peoples’ opinions about this.
Although I’ve been an active member of the IxDA for a while (I run the Brisbane group and have been to some of the conferences), I’ve never had much to do with the UPA, other having paid the membership fee for one year and feeling like I got a huge amount out of it.
Does anyone else have any experiences with them?
Remote collaboration setup and etiquette
One of the key mantras of Agile is working in co-located teams. Despite this most of my recent projects have involved a distributed team. It seems to have become inevitable that for one reason or another teams can’t be permanently based in the same space.
While I believe that co-location is still the ideal, it doesn’t mean that distributed teams can’t also be productive.
Over the years of being on both sides of the physical divide (both with the majority of the team or by myself) I’ve learnt that a few simple set-up points or attention to basic etiquette can make all the difference.
Here are some of the things I’ve learnt. To me some of these seem really obvious, but based on personal experience over the years I don’t think they are so hence I felt the need to put up a post about it.
Have an always-on channel across locations
Set up a video call to connect the different locations and leave it on the entire working day. Picking-up the phone and calling really is a big barrier. Being able to glance over and see the other team or just walk up to the screen and ask a question makes a huge difference is bring remote teams together. I’ve seen this work effectively in a variety of situations. For offshore teams split across two countries, or just projects where the majority of people are based in one room with a few people in different locations.
In one recent project we had a team based in Melbourne, with individual people dialling in at various times from Sydney, Brisbane and London. A Google+ Hangout was left always on so team members working remotely could dial-in from where ever they were at the time and still be connected to the team. Here’s a pic of the main project room, you can see the TV up one end of the room with a laptop and camera next to it running a Hangout. It also led to some fun and games playing with people’s titles.
Ensure there is some face-face contact
It is important to have some face-face contact to get to know people and build a rapport, particularly early on in a project, ideally at the start. The cost of flights & accommodation do add up but having actually met your team members in person makes a huge difference. Even for non-distributed teams the simple act of going out for dinner & drinks together can help break down all the barriers.
Get a mic in the middle of the conversation
When you have a team broadcasting itself, make sure the mic is in the middle of the conversation and can pick up everyone equally well. Having the microphone at one end of the room, say at the end of a conference table, will always result in the people at the other end of the room being barely audible.
Separate the mic and camera
Webcams that have an inbuilt mic aren’t good for groups. You can’t just hang one up at one end of the room where it provides the best view and then expect to do both. This is usually the worst place to put a mic. One of the simplest ways to do this is to use a traditional Polycom phone in the middle of the room for audio (which is usually the best quality audio option) and then put a webcam in a corner hooked up to a TV with Skype running the video (but muted). This is also more reliable as even if the video starts having problems you can still keep talking.
Put a camera in a corner where it can see the whole room
This allows anyone remote to see who’s talking, etc. Being able to see the whole room makes a big difference to feeling like you’re in there.
Add a second camera that focuses on the whiteboard/wall
While the detail on the wall probably can’t be read in fine detail, being able to roughly see what everyone else is focussing on helps draw the remote person in to the room. This is where having a video conferencing tools such as Google Hangouts come in to play. Two or more people in the room can dial-in to provide different perspectives of the room.
Use a ‘chaperone’
If you have a meeting in a room when only one person is on the phone, have someone in the room ‘chaperone’ the remote person. This person becomes responsible for making sure that any audio/video set-up is working and adjusted when necessary. For instance maybe moving a webcam to keep it focussed on the right spot in the room. In workshops this person can write down the ideas of the person on the phone and add them up on the wall. A great example of this taken to the extreme is George Bluth’s ‘surrogate’ in Arrested Development
Try to project your voice
Over the years I’ve developed a ‘conference phone’ voice where I speak slightly louder and try to be clearer (kind of like my talking to a non-native English speaker voice). However, not everyone feels as comfortable doing this so…
Position quiet people closer to the mic
If someone is more softly spoken, recognise it and move him or her closer to the microphone. Likewise, do the opposite for people who have no problem projecting their voice.
Watch out for people creating noise that disrupts the audio
I’ve lost count of the number of times I’ve seen someone sitting right next a mic tapping away at a table, flipping open/closing their phone, etc. On the other end of the phone all you can hear is a banging noise and not the conversation. It’s a simple matter lack of awareness that can completely disrupt a call.
Mute yourself if you’re not talking
No one likes having to call out a heavy breather. And all the background noise adds up.
Level the playing field, have everyone dial in
It goes against the co-location idea a little, but I’ve found that in some situations it’s far more affective to have everyone dial-in to a conference call, even when a group of them are sitting in the same area. This puts everyone on the same level and gives everyone their own individual mic, i.e. their own handset. When teams have regular calls where everyone is giving weekly WIP updates it lets everyone sit at their desk and partially listen in rather than falling asleep in a meeting room where they can’t be heard very well when they do need to say something.
Recommended tools
- Audio
- POTS (plain old telephone system) and conference phones are still the most reliable.
- Skype can be good for audio calls, but I’ve found running video tends to make it lag after longer calls.
- Video
- Skype is a simple favourite for 1-1.
- For multiple people Google+ Hangout have become a tool of choice as it’s free, anyone can dial in without needing to be added (a downside of Skype), there in no limit to number of people, and you can share screens. There are plenty others out there but Hangouts seem to be the least restrictive.
- Hardware
- MacBook pro built-in mics work quite we in a room to capture audio, but they need to be in a central location.
- Logitech HD Pro Webcam C910 provide both good quality audio & video at a reasonable price.
Tips for writing clear, compelling and concise content
One the most undervalued roles in a web or software development team is that of a Copy Writer/Content Strategist. Having a skilled specialist on a team who is able to set the tone of the conversation with users and ensure that it is consistent across the site can make the difference between a mediocre or great product.
Unfortunately, it’s rare to have a dedicated Copy Writer on a team unless the product is either content heavy or marketing driven. Largely the duty of authoring all those small but important bits of text tends to fall to the User Experience Designer and Product Manager/client when creating and reviewing wireframes.
In the worst-case scenario it gets left with the Devs to do when they are building pages. In this case instructional text, error messages, field labels, etc. end up sounding like the have been written by an emotionless robot. This is not a slight aimed at the English skills of my technically minded colleagues, but more a reality of what happens when copy is produced as a by-product of writing functional code.
Recently a colleague of mine, Meaghan Waters, shared a set of content writing guidelines, which had previously been shared with her by an old colleague, Amy Teshio.
It has some great tips and reminders on how to write compelling content. I found it so valuable and helpful that I had to share it here as well:
Clear, Compelling, Concise
Like most things in life, good writing is about thinking and feeling:
- If you can think clearly, you can write clearly.
- If you are passionate about what you have to say, your text can be compelling.
- If you can be dispassionate about how you’ve said it, your text can be concise.
Some tips:
Believe in your message.
Trusts its value. Let it speak for itself. Tell stories. Know when to move from information, to story, to visual rendition, back to information, etc. (or consult with others).
Get it down on screen/paper, then revise.
Let the flurry happen. Put it aside and come back with fresher eyes. Consult with our editorial team. Give yourself enough time to draft, consult, revise. Writing is different from editing. Don’t try to do them simultaneously.
Edit, edit, edit.
Remember, just because you are reluctant to give up a particularly nice word, sentence or paragraph doesn’t mean the reader will miss it. If you are having trouble giving it up, copy it to a separate file and make it your own buried treasure.
“Vigorous writing is concise. A sentence should contain no unnecessary word, a paragraph no unnecessary sentence, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”
William Strunk, Jr., The Elements of Style
Vary your sentence length.
Mix up the rhythm. It keeps it interesting and sounds less robotic.
As a general rule, a good sentence contains one idea.
If you have another idea to convey, start a fresh sentence.
Find your voice and stay with it.
Know your audience.
Voice should reflect subject matter.
Use the appropriate tone:
- Formal vs Casual
- Serious vs Humorous
Use active verbs. Avoid “to be” constructions and the passive voice.
No: The white iPhone is preferred by generation Xers.
Yes: Generation Xers prefer the white iPhone.
Stay close to the idea.
Don’t put too many qualifiers between you and your message. This attempt to be conscientious will only confuse the reader. Readers don’t retain ideas that are in remote locations.
Don’t say “perambulate” when you can say “walk”.
Avoid jargon. Use the simple, reliable work. Good writing is not so much a matter of using unfamiliar words, as using familiar ones in unfamiliar ways.
Watch stuff like:
Three factors of influence versus three influences.
When talking to different participants, paper copy remains a critical component of the way they manage day-to-day information.
But note: paper copy didn’t do the talking to the different participants.
Avoid passive voice/double gerunds.
No: The e-binder concept form was seen as a way to provide a format for organizing sharing.
Yes: Participants see the e-binder as a way to organize the sharing of information.
Why learnings instead of lessons? Why around instead of about?
What’s on my UX bookshelf
I regularly find myself giving a list of recommended reading to people who are looking to learn more about UX design or a specific topic. It usually ends up being the same 3-4 books that I recommend, but after one of these conversations recently I figured I’d take a few minutes to run through my bookshelf and put together the extended list of all the books + blogs that I’ve read and would recommend. This is by no means meant to be a comprehensive list of all UX good books, just the ones that I’ve had the time read.
General UX books
 |
The Design of Everyday Things, Donald A. Norman *most often recommended A classic read from one of the gurus of UX. This is my favourite book to recommend to people who are just starting to understand and appreciate the importance of UX. It highlights the amount of design that we encounter and use on a day-to-day basis without ever noticing – which is a sign of successful design. After reading this you’ll never look at door handles the same way again. |
 |
Emotional Design: Why We Love (or Hate) Everyday Things, Donald A. Norman Don Norman’s follow up book which shows the journey he went on as a designer, where he went from focusing primarily on aesthetics/form to appreciating the impact that emotions and psychology have on the way we experience design. |
 |
The Elements of User Experience: User-Centered Design for the Web and Beyond, Jesse James Garrett This is best, most straightforward explanation I’ve found that can articulate the difference between Interaction Design, Information Architecture, Visual Design, UI Design, and how all this hangs together to create a website. |
 |
The Inmates Are Running the Asylum, Alan Cooper When it was first released this book challenged the common approach to design as being something that was done in a token way after the engineers has done all their hard work. This once pioneering book has now become a bit dated in my eyes. Not because it is any less relevant, but just because there are very few companies that don’t at least nominally acknowledge that user experience is important. Whether they do anything about it is another matter. It’s still a worthwhile read, but nowadays it just feels a bit like it’s stating the obvious. |
Usability
 |
Don’t Make Me Think! A Common Sense Approach to Web Usability, Steve Krug *most often recommended The is the classic book about web usability and how easy it can be get it right if you approach it the right way. A must read for anyone starting to get it to UX, and best of all it can be read in an hour or three. |
 |
Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, Steve Krug *most often recommended The companion book for Don’t Make Me Think that is the best step-by-step guide to conducting usability testing you’ll find. Krug’s basic point is it really is straightforward and anyone can do it. This books shows you how easy it can be. This quick to read book will leave you ready to start conducting tests that day. |
 |
Web Form Design: Filling in the Blanks, Luke Wroblewski This is the book that I am the most thankful that someone took the time to write. Luke W. does a great job of answering the questions about how people use web forms. While he rightly doesn’t give any absolutes about what is the best layout, he provides research based insights to understand how all the little details, such as label placement, affect usability and can be applied. They seems like such small details, but anyone who has designed a web form knows just how important these details are…and how much time can be spent debating them. |
Design
 |
Universal Principles of Design: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design, William Lidwell & Kritina Holden & Jill Butler A comprehensive collection of general design principles and concepts that can be applied equally across the various design disciplines. It covers anything from Gestalt principles, to colours, and storytelling. If you want to add some theory behind how some design patterns work, this reference does a great job of explaining all the concepts with visual examples. |
 |
Designing for Interactions, Dan Saffer A good general overview about what Interaction Design is, how it works and how it fits in to the overall design landscape from one of the better known Interaction Designers, Dan Saffer. |
 |
Thoughts on Interaction Design, John Kolko An intellectual look at the emerging field Interaction Design and how it can make a difference. John Kolko is one of the more inspiring Interaction Designers out there. He ties design theory in to making a practical difference. It provides some great challenges and food for thought for experienced IxDs. |
 |
Envisioning Information – Edward Tufte Tufte is one of gurus of information design and visualisation. This beautiful book uses historical examples from all over the ages to explain the subtle nuances of communicating information when designing maps, diagrams, data sets, etc. |
 |
Designing for People, Henry Dreyfuss An old time classic, from one of the pioneers of Industrial Design. Written in the 50′s when the manufacturing boom generated the need for well-designed products as a differentiator, this book gives an insight in to how designers changed the world of physical objects; just as the UX profession is doing to the digital space now. It’s fascinating to the see the parallels. |
 |
101 Things I Learned in Architecture School, Matthew Frederick Some great design food for thought. UX design shares a large amount of knowledge, principles and practices with Architecture. There is a lot we can learn from this well-established discipline. Similar to the Universal Principles of Design above, this book captures some general principles that can be applied to lots of different areas. |
 |
Getting it Right with Type: The Dos and Don’ts of Typography, Victoria Squire Good typography is a key element in any kind of design work. Having a good understanding of how it works is something that everyone can benefit from. |
Strategy & Planning books
 |
Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, Alexander Osterwalder & Yves Pigneur The Business Model Canvas is one of the most useful tools you can find to help drive and inform product strategy conversations. |
 |
Subject To Change: Creating Great Products & Services for an Uncertain World, Peter Merholz, Todd Wilkens, Brandon Schauer, David Verba A great book on the changing nature of business and how to produce innovative products. Focused on the strategic side of business. |
 |
Rework: Change The Way You Work Forever, Jason Fried & David Heinemeier Hansson This captures the essence of start-up culture and how to work effectively in small teams. For people working in large bureaucratic organisations this can seem like a fantasy-land utopian state, but a lot of the mindsets and approaches can be adopted regardless of where you work. |
 |
Zag: The Number One Strategy of High-Performance Brands, Marty Neumeier If you need some inspiration about how to think outside the box and be different in your product strategy, this book helps outline how to embrace an innovative mindset. |
Human Behaviors
 |
Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi We all experience being in-the-zone, a.k.a. the flow. Some of us try to design for it, but few people really understand the psychology behind how it works. This captures the insights of someone who has dedicated years to understanding it. |
Agile & Lean
 |
The Lean Startup, Eric Ries *most often recommended This book has started a movement. Eric Ries, with his Build-Measure-Learn cycle provides a language and a methodology for reframing the way we run businesses and products. The best part is that it isn’t just for people in garage start-ups. It applies equally to enterprises. |
 |
Agile Experience Design Lindsay Ratcliffe & Marc McNeill Another book that falls in the category of books that I’m glad someone took the time to write. Fellow ThoughtWorkers Lindsay and Marc have put pen to paper to capture the approach and techniques that we use to experience the benefits of going Agile. |
 |
The Toyota Way, Jeffrey Liker One of the must reads for anyone looking to learn more about Lean and Agile practices. |
Tools & Techniques
 |
Designing for the Digital Age: How to Create Human-Centered Products and Service, Kim Goodwin A great reference book and how to guide for the UX/Interaction Design process. It covers everything from project inceptions, through research, prototyping, and on to detailed interaction design. Not something you’ll read from cover to cover but great to be able to refer back to when you need to figure out/remember how to do something. |
 |
Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, Dave Gray & Sunni Brown & James Macanufo For anyone who runs a lot of workshops or activities this is a great resource. The games themselves are useful for inspiration, but it is worth reading just for the first chapter that explains the structure and mechanics of how games work. |
 |
This is Service Design Thinking: Basics – Tools – Cases The first book to be written that is dedicated to Service Design, it gives a good overview of what it is all about, the tools and techniques used, and some useful resources/templates to help get started with it. It’s also a beautiful example of information design in itself. |
Research methods
 |
Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics, Thomas Tullis, William Albert If you want to tighten up your research methodology and back up your findings with solid stats, this shows you how to do it. |
 |
Observing the User Experience: A Practitioner’s Guide to User Research, Mike Kuniavsky A great capture and explanation of the tools and techniques in the UX research toolbox. |
 |
Mental Models: Aligning Design Strategy with Human Behavior, Indi Young Mental models are one of my favourite tools for communicating research findings and human behaviours. A simple, but effective tool this book will show you to create them. |
Sketching/Prototyping
 |
Sketching User Experiences: Getting the Design Right and the Right Design, Bill Buxton *most often recommended Bill Buxton of Microsoft fame outlines the philosophy behind sketching and prototyping products. He highlights that value of exploring ideas with sketching and prototypes before launching in to the more costly build phase. It’s also filled with great case studies. |
 |
The Back of the Napkin: Solving Problems and Selling Ideas with Pictures, Dan Roam A great guide for anyone trying to improve the use of their sketching skills as a facilitator. It’s not so much a how to guide for drawing, but more a way to help visualize and explain problems. |
 |
Prototyping: A Practitioner’s Guide, Todd Zaki Warfel A good overview of creating and using prototypes. It’s main focus is an in-depth review of the prototyping tools that were around at the time of it being published, full of great tips and techniques on how to use them. |
Design Blogs that I read
Some good user experience/interaction design/information architecture/graphic design blogs that talk about tools, techniques, resources and challenges:
- Box and Arrows
- Smashing Magazine
- UX Matters
- Johnny Holland Magazine
- Core77
- A List Apart
- UX Magazine
- 52 Weeks of UX
- Wireframes Magazine
Well known people’s blogs
Future Perfect – Jan Chipchase
Jan Chipchase was once described to me by one of his colleagues as the ‘Indiana Jones of the design world‘. He’s been conducting international ethnography research for many years now. His blog is generally a collection of photos and thoughts from all over the world. Great for remembering that there are other countries and cultures out there. He makes me jealous of his experiences, but grateful for being able to regularly sleep in my own bed.
Jacob Nielsen’s Alertbox
The blog from the self-styled ‘guru’ of Usability. Jacob Nielsen was one of the pioneers of web usability and has been preaching about his research findings and usability guidelines for years. While he can be criticised for focusing on a very narrow view of user experience and placing no value on design (his unchanged website design has been proof of this for years) he does still come up with some useful research based insights from time to time.
User Interface Engineering Brain Sparks
Another celebrity of Usability, Jared Spool has been blogging and talking at conferences about usability and interface design for years. This blog is a thinly veiled marketing vehicle for UIE conferences and seminars, interviewing industry experts about topics that they are about to present on. However, this doesn’t stop its articles and interviews from being worth listening to.
Good Experience
A blog from Mark Hurst who has been blogging about customer experience, user experience, human experience since before UX was called UX.
Ask ET
A discussion forum about Information Design, hosted by Edward Tufte, the guru Information Design.
Cooper Journal
A blog about design, business and the world we live in from the company that bears the name of Alan Cooper.
User Experience & Interaction Designer. Researcher. Design Thinker. Ideator. Collaborator. Visual Thinker. Sketcher. Agile Believer. 
