There has been a lot of talk about ethics in UX circles over the last couple of years. This is a good thing. However, most of it has not been actionable in everyday work. And, to be honest, most ethically problematic products weren’t designed to be unethical. I am quite sure the designers of smart thermostats, easier purchase flows, sharing economy apps and social networks didn’t expect that their work would be used for domestic abuse, unwanted purchases, worker exploitation and skewed world views. In my experience, UX designers are generally a group of people who believes in the good of their fellow humans which means most of the time they don’t even consider how their designs could be used in unintended ways that might be harmful or dangerous. But maybe we, as a group, should. Maybe we should try to imagine the worst ways our designs could possibly be used as a part of our design process so we can at least try to mitigate the risk of that happening.
Anneli Olsen
Anti-Agile Personalities – Part 2
In my previous blog post I listed personalities on the management side that stood in the way of efficient, modern product development. In this post, I will cover some of the personalities you might find in the actual development teams.
Continue readingAnti-Agile Personalities – Part 1
The technology development is going in lightning speed nowadays and almost every company has at least 10 competitors who can offer their customers the same or better experiences or goods. This puts quite a lot of pressure on companies and organisations to be nimble and customer focused which in turn does the same on the people working for them. Certain traits have become more important in employees than before, whether it is management or development teams, such as trust, flexibility, passion, curiosity, ability to collaborate, humility, and innovativeness. It also means that personalities not defined by these traits that still worked very well in traditional, hierarchical organisations actually might be obstructing efficient development in modern organisations.
UX – It’s obvious, right?: Part 3
In the talk I gave at Agila Sverige in June, I brought up misconceptions about UX I’ve encountered during my years in the IT business. One of these is that it’s only the UX people (and possibly the PO) who need to meet the users. In this post I’ll discuss why this not true, but also how meeting the users can make a real difference in focus and motivation for the team.
UX – It’s obvious, right?: Part 2
In June I gave a talk at a conference about things that I, as a UX professional, find obvious that I have noticed that others don’t. After giving the talk, I decided to also put it down in writing as a series of blog posts. This is part 2 of that series and talks about that even if you hire usability experts, they still need to meet the users.
UX – It’s obvious, right?: Part 1
I did a talk at the local conference Agila Sverige in June about things that I, as a UX professional, find obvious about UX, but that I have discovered that other professions might not. I actually felt really nervous giving the talk, because I feared that I had been mistaken and the things actually were obvious to everyone. I needn’t have worried…
The Minimum Loveable Product
I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.
Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.