I spent a good chunk of last year designing and user testing a ‘virtual assistant’ for a major entertainment brand. So I was interested to read a pair of articles from Neilsen Normanabout chatbots and intelligent assistants. Our virtual assistant worked liked the former, with text input and a chat interface. But it had the increased intelligence of the latter.
On chatbots, NN/g say:
These bots simply replicate functionality that is already available on the web or in mobile apps. Is it worth spending time and money for this new channel? Unlikely — at least in the US and other countries where the traditional channels are already well-established.
This was definitely a question we heard. We faced scepticism over whether we’d created a worse-than-useless chatbot who’d insist on doing site searches for you. If you’re old enough to remember Clippy, you’ll know this feeling.
Things get more promising when it comes to ‘intelligent assistants’ like Alexa (emphasis mine):
Continue reading “What we learned designing a virtual assistant”
Users have great difficulty accomplishing advanced tasks with traditional computer systems: only 31% of the adult population in rich countries are capable of performing tasks similar to the multitask and research needs in our table, when using traditional user interfaces. Since more than two thirds of the population don’t have the required computer skills for doing anything advanced with current computers, there’s great potential for helping these many peopleif the intelligent assistants were in fact good enough to take over the tasks.
We have a few new Experience Consultants starting this month, so I asked the team which books had helped them most in their UX careers. Here are five of my favourites:
This is one of the classic introductions to UX and is worth reading in its entirety (it’s an easy read).
Mike Monteiro explains that doing design isn’t some mystical art, it’s helping a client solve a problem (and getting paid to do it).
Continue reading “5 books to read if you’re starting out in UX”
For the past few months I’ve been thinking a lot about purpose.
Like many people I’ve been inspired by Frederic Laloux’s work on next-stage organisations. ‘Evolutionary purpose’, along with self-management and ‘wholeness’, is one of the three big elements of next-stage organisations. Purpose is:
a powerful drive to do work that has meaning and purpose. The concept of ‘being the best’ becomes a hollow aim unless the organization is doing something worthy of the energy, talents and creativity of the people who work there.
The Reinventing Organizations wiki
I help run a meetup called Reinventing Work: Bristol. We agreed early on that we didn’t want this meetup to become a talking shop. But we did feel we needed to start by defining what we were meeting up for. So we decided to spend our first couple of sessions defining our group’s purpose. These are my thoughts on that process.
At Edo we recently began offering a 9 day fortnight, as part of our journey toward being a next-stage organisation. I wrote about it for Corporate Rebels:
Last month, our Head of People Claire shared the exciting news that we were going to offer the option of working a 9 day fortnight. With the new financial year on the horizon, everyone would be able to choose between receiving a pay rise, or having every other Friday off.
Edo is a design and technology consultancy in Bristol, UK, with a permanent staff of about 25. It’s always been a good place to work, with a healthy work/life balance. But we knew some of our approaches were informed more by how we thought things should be done than what we really needed.
There was too much process and hierarchy. Our journey has been influenced by Frederic Laloux and sites like Corporate Rebels. Less hierarchy, more autonomy, and greater wellness and purpose at work began to feel like the solutions we needed.
Read the rest at Corporate Rebels.
I wrote this blog post with Jess from People For Research, about how to design the best research experience:
There’s no one perfect way to do user research. Every method has its pros and cons. The key is to design the research process. Just like anything else you might design (a website, a gadget, or a garden) it’s about:
Defining the problem(s) you want to solve
Coming up with a solution that works within the constraints of time and budget
Read the rest at People For Research.
User stories spreadsheets are an important part of any project, but they make it difficult to keep your eye on the big picture. Here’s how we’re using story maps to improve the requirements process.
Defining requirements is a key part of user-centred design. At the end of a block of research we have a load of insight into user needs- top tasks, motivations, pain points, emotions and more. Turning this into a tangible list of things to prioritise (then actually do!) is vital.
What we used to do
Our old method will be familiar to anyone who’s ever worked on a website or software – user stories. First, we’d put every requirement in a spreadsheet, one per row. These might be user requirements, business requirements, or technical requirements. Then, we’d get the project team in a room and spend the next few hours prioritising them. The advantage of this approach was the detail. Every requirement- user, business and tech- was graded and ranked in relation to every other requirement. The disadvantage was that the process didn’t serve the needs of its users – the project team. Spending four hours in a hot meeting room updating a spreadsheet is boring. Really, really, boring. Once, somebody said they were going out to send an email and didn’t come back for two hours.
After significant time and effort doing research and sharing our findings this process set us up to ignore user needs, and instead focus on out-of-context details. We needed a new approach.
What we do now
So we decided to try story mapping, based on Jeff Patton’s book, User Story Mapping.
As Patton says, “Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does.” So not only is the process of user story prioritisation a hard slog, it guarantees the project team loses sight of what it is they’re actually making. “Building a user story map,” on the other hand, “helps us focus on the big picture – the product as a whole instead of getting myopically focused on an individual story.”
Continue reading “How story mapping is helping us humanise requirements”