patkua@work

The intersection of technology and leadership

Category: User Experience

Book review: “This is service design thinking”

A couple of years ago, a very kind Product Manager gave me a book called “This is Service Design Thinking.” It was shrink-wrapped and everything after they had received it on a training course. I finally got around to reading it this weekend. The book is beautifully made… hard cover, thick pages and even with little coloured book mark ribbons strewn throughout.

I consider myself lucky, having worked with many different user experience folk who have helped shape my understanding of Service Design and this book helped to add a few more tools to my toolkit and a nice way of trying to shape it. When we write software, we already incorporate a lot of the design thinking concepts – really trying to understand the “touch points” that a customer has with an organisation and how software fits into these different needs. We don’t always get to work at a high level of an organisation – something that I believe is necessary if you are truly going to help shape or influence an organisation’s service offering to customers. Software is only one part of the puzzle. However it is becoming more and more relevant as software (or hosted software) starts to become a major or only channel for service delivery to customers.

This is Service Design Thinki

We already make use of many of the tools described, but a few new ones to me included:

  • Service safaris – A nice name for the technique of visiting people to observe them interacting with an existing service.
  • Cultural probes – The “probe” in a scientific sense but basically a kit given to customers to allow them to take snapshots of their own life in the context of a service to build a greater awareness of what’s important to them. These probes stay with candidates for a while but a researcher may send texts or emails to prompt for a different insight. Requires constant attention to the information being submitted back
  • Expectation maps – Building a visualisation of what a customer expects when they interact with a service. Useful for comparing different expectations across different touchpoints, or offerings.
  • Desktop walkthrough – I haven’t seen this technique probably because it seems to demand more preparation than others. Basically this is a 3D small scale model of a service environment that allows people to interact with it. I can see this being highly engaging.
  • Service Roleplay – A scenario where staff members are asked to enact several situations where they might come into contact with a customer. Video is often used to provide feedback and act as a basis for discussion.
  • Customer lifecycle maps – A holistic view of a customer’s relationship with a service provider. Their example one maps out loyalty over time. I can see the map being annotated by events to trigger insight

I really enjoyed the book. There are some nice studies at the end. I did protest at the simplified description of “Agile software development” but it’s small detail in the larger set of things. My only gripe is that the beauty of the book comes at the price of being significantly heavy to lug around.

Reflections on Agile 2012

Another year, another agile conference. It’s time for reflecting on the conference and uncovering lessons learned. Dallas, Texas hosted this year’s Agile Conference. More accurately, the Gaylord Texan Resort in Grapevine hosted this year’s Agile Conference. Loved by many at the conference (notably less so by Europeans) the resort reminds me of the Eden Project and a weird biosphere (see picture below) that is self-contained and fully air-conditioned. Although maybe this wasn’t such a bad thing with a West Nile virus outbreak in Dallas.

Needless to say that I stepped out quite a bit to try to get some fresh, if not, refreshingly humid air.

Onto the conference. It was very well organised, very well run and even rapidly responded to feedback (such as moving rooms when demand proved too much for some of the anticipated sessions. Food came out very promptly in the different breaks. We didn’t have to queue too long and the variety was pretty good. The only breakdown was probably the Tuesday lunchtime where it wasn’t clear we had to get our own food and with a limited number of on-site restaurants in our self-enclosed bubble world, proved to be a bit of a tight squeeze in schedule.

The people at the conference seemed to be a bit of a mix. Mainly lots of consultants like myself sharing their experiences, but as one person noted, an extraordinary number of agile coaches all apparently looking for work. On the other extreme there seemed to be lots of companies adopting agile and lots of people selling tools and training to help them.

Lots of parallel tracks meant lots of choice for many people but I often found it hard to find things that worked for me. I’m less interested in “enterprise agile adoption”, and more interested in the practices pushing the boundaries, or the deep insight offered by people. The few technical sessions I went seemed to be aimed at a bit more of an introductory audience. I particularly avoided any of the “do this with scrum” or “do this with kanban” as these appeared by be pushing.

In terms of keynotes, I thought they did a great job of assembling some diverse and interesting sessions. Although Bob Sutton (No A**hole Rule author) felt like he didn’t do much preparation for his keynote from the text heavy slides that jumped at different paces, he had some good anecdotes and stories to share. My biggest takeaway from that session was thinking about taking away practices just as much as adding practices, something that I think I do implicitly but should try to do more explicitly. The other keynotes were pretty inspiring as well, with Dr. Sunita Maheshwari behind Telerad talking about her accidental experiment moving into doing remote radiology to support the night-shift need of hospitals in the US and the interesting growth of their business. The other really inspirational keynote was by Joe Justice, the guy behind the amazing Wikispeed project taking sets of agile practices and principles back into the car-making industry. I felt he really knew his stuff, and it’s amazing how you can tell someone who really understands the values and trying to live them in different ways and then translating them into a different world. Very cool stuff that you should check out.

In terms of other workshop sessions, I left half way through many of them as the ideas were either too slow, or not at all interesting (such as one on Agile Enterprise Architecture that spent 30 minutes trying to go back to the age-old debate of defining Enterprise Architecture.)

Two of my most favourite sessions was one by Linda Rising who gave a very heart-felt and personal Q&A session that left many people in tears. Her stories are always very personal, and I really admire her ability to look beyond someone’s words and really uncover the true question they are asking with a usually insightful answer as well! The other session was listening to the great work that Luke Hohmann of Innovation Games has been doing with the San Jose government to change the way they make decisions about where the money goes through the use of games and play. Very awesome stuff.

I had my session in the last possible slot on the Thursday and had a large number of well known people in competing slots such as Jeff Sutherland, Esther Derby and Diana Larsen. I’m very happy with the turn out as we had a lot of fun playing games from the Systems Thinking Playbook including a number of insightful conversations about systems thinking concepts and how they apply to our working life. One of my most favourite exercises (Harvest) that demonstrates the Tragedy of the Commons archectype played its course and we finished in just three years (iterations) only due to a constraint I added early into the game. I love this exercise for its potential for variation and the insightful conversations about how this applies to agile teams, organisations and functions.

You often can’t come away from conferences without new references, so here’s the list of books and web resources I noted down (but obviously my summary is without actually reading into it, so YMMV):

Long Feedback Loops

Almost five and a half years ago, one my first project in the UK, I built a constrained email tempting engine to be used by marketing folk with a small team of three other developers. I think we worked for about six to eight weeks to develop the entire application, including retrofitting its integrate its output with another system.

A year or two ago, we had some consultants return to the client who talked to one of the original developers who still worked for the same client. They spoke fondly of the good times he had on our team, and spoke proudly about the application we wrote. In the four years or so of constant use (they would revisit their emails at least once a month), the users apparently only ever reported one bug. He mentioned that bug (a special character in the email subject line) was also deprioritised from the original work we did. It was an enough fix and with test around it, was not a problem updating the system.

I certainly appreciated the feedback, particularly since you don’t always get to return to see the long term results of the work you do as a consultant, or even just as a developer.

Some of the great things I learned from that project.

Acceptance Test Driven Development is entirely possible
We worked hard to test drive this Swing based application from the start. It really changed the way that we designed the application and all of us learned a whole heap about understanding testable presentation patterns. It formed the basis of several talks and the knowledge, particularly the separation of concerns is entirely applicable to all sorts of other tools and interfaces such as javascript, or command line interfaces.

On a different note, coverage combining end to end acceptance test and unit tests meant we had 100% code coverage. It was never the goal, but interesting to see on this application it was entirely possible.

Never discourage people from trying new things
The organisation was rife with contractors. Not all of them entirely passionate. I love building great teams and the fact that everyone was learning, and saw things being delivered reignited people’s passions to do various things. I distinctly remember two events made possible by encouraging people to explore their passions and strengths.

One of the developers, interested in the User Experience side asked if he could do some user testing with the application. I can’t remember exactly what I said, but certainly encouraged him to do that. He did, what some people call Guerilla Usability Testing – grabbing someone who didn’t know anything about our application, and giving them a task list to complete as he watched them over the shoulder. Based on this study, we found out, to no surprise, the way we laid out the application didn’t make some of the tasks as easy as they could have been. We channeled this feedback into our interface and helped make life easier for its users.

The other event, a contractor, seemed to find his passion for developing usable software reignited. Everyone will know that swing applications aren’t the nicest things to look at. I remember coming in one morning to find that whole interface reskinned and redeveloped. It looked a whole load better than what you’d get with swing out of the box.

I found out much later that he had, by his own volition, worked a couple of extra hours one night because he wanted to add that extra polish and make the interface attractive to users. Awesome stuff that would never have happened without encouragement to do “the right thing”.

Involving real users
As a systems thinker, I know that the purpose of the project should have been an intermediate step. The real problem the organisation was a missing feedback loop from IT back into marketing. I knew that then, and I know that know, however being pragmatic and realistic, you can only do good things within your own sphere of influence. Trying to change how the entire marketing and IT department silos worked (or failed to work together) would take much more than the two or three months I was going to be there.

Fortunately, we had one person on our project who had worked for their company for a while and had a couple of good contacts in marketing. Whilst we couldn’t change the way projects spun up, we managed to get someone who was going to use our software down, early, and show them what we were building for them. More than that, they asked for somethings (that we could almost immediately turn around for them) and they were blown away that their feedback actually mattered and made a difference.

Conclusion
I appreciate good projects, and where possible, create those environments for others to thrive in. There are many good things to carry forward in these things and can only hope others benefit from it as well.

Putting the “user” into user stories

I’m helping to kick start a project where we’re identifying enough user stories to help build a solution towards a tight deadline for legal compliance. We’ve been making great effort at identifying and talking through the users of the system, particularly exploring how difference users have different needs. We’ve managed to talk to existing users of a similar system, and talked to people who will manage the new users. The hard bit is that our real system users don’t even exist yet.

My work colleague, Alex McNeil, will be proud that I’m pushing for the UX flag and we’ve finally got a UX person onboard which I’m delighted with. I think it’s worth fighting for guerilla UX whenever and however you can get it. In this case, more is always a better thing for end users. I want to be proud that users actually use all the features we build and enjoy using them at the same time. Without properly understanding who they are and what they are trying to accomplish, I’m confident we would have ended up with a naff system.

Also, unlike some developers who want to jump in and start coding, this part of getting into the mindset of a user you’re targeting is a key attribute to the proper use of user stories. Focusing first on understanding what problem your users are trying to solve is the key to building what is actually neeed. I’m not the only one in the agile community to feel this way, with many people inverting the classic and now dated, “As a … I want … so that … “ story format made popular in User Stories Applied.

We’ve made plenty of headway in the right direction and although I know we can take the UX much further, constrained by client expectations, time-conscious of a pending legal deadline. Don’t worry though. We’ll be trying to live out another agile principle of getting fast feedback, even if its done using other guerilla user experience methods.

I care about emphasising the user in user stories because I don’t want to be responsible for one of those systems people loathe to use. I hope you will care about it too.

Agile Principles Applied to Training: Building in Quality and Continuous Improvement

In my experience, achieving high quality is a key part to being adaptive and nimble. Continuous improvement and responding to the feedback allows you to achieve high quality. Here’s what I’ve applied to training so far:

  • Set design and collaborating ideas – One approach I could have taken to developing the material included simply writing the content, trainer’s guide, handouts, etc and run it with a single class before trying to change anything. Instead, I came up with a few options, bouncing ideas off someone else who’d run training before and asked them, “I’m thinking of trying something like like …, I imagine it would work like … and we’d achieve … What do you think? What discussion would this generate? Would people find it engaging?” It stopped me detailing things too early and putting in too much effort that would need rework.
  • Worksheet EvolutionUser Centred Design – For some of the worksheets, I applied some principles from Don’t Make Me Think, testing them out with some users to make sure they needed as little instructions as possible. It’s important for students to have a good experience with everything to do with the course. You can see the evolution by looking at the picture above – it’s a worksheet for introducing the concept of velocity for the XP Lego Game.
  • Finding the right metrics to use – I’ve already changed my feedback forms since running the pilot programs, looking at what information I actually consume and how people use it. I used to have a two-page feedback form, the first including instructions and a focus on multiple choice answers, with the second page using a more free form format. Since I hand them out in class, I give verbal instructions and removed the detail blurb I had at the top. I also condensed the form into a single page, and focused on three key questions I am more interested in – “What did you like best about the session? What constructive changes would you suggest to make the session more effective? What else do you want to know about?”

Please Don’t Tell Me What I Like

Ticketmaster sent me an email this morning suggesting a concert for, apparently, “one of my favourite performers”.

Ticketmaster

They’re as far off as they could be. Much as I have a lot of respect for some of the music this artist produces, I doubt I’d ever place it on my favourite artist of all time list. Ever.

Respect for customers is really important in today’s world. Choosing what language and words you use demonstrates this. It’s even more important if you only send emails.

Amazon uses recommendations or suggestions when offering alternatives, as they know they get it wrong sometimes. At least they’re honest about it. In case you wonder, I prefer a more local site (GigsAndTours.com or Stargreen.com) for buying tickets.

Airline Customer Service

In trying to change my return flight to London from Bangalore, I’ve been trying to reach British Airways. Calling two of their numbers (the only ones given to me in fact) resulted in the following experience:

*Ring*, *Ring*

“This is British Airways. You have reached our India free number. This service is currently unavailable. Please redial using the advertised number.”

*Click*

That’s it. No greeting. No explanation. No alternatives. A simple message offerings many lessons to learn from.

Dear Microsoft Connect Feedback

Thank you for responding to the issue that I raised (located here) about a problem how one of your ASP.Net 2.0 Framework controls and Internet Explorer (and only Internet Explorer) fail to work well together.

I’m very happy that the time that I spent detailing the steps to reproduce the problem was well spent and that, you too, were able to reproduce it. I’m quite disappointed that we have not made any progress on fixing the problem and the solution offered to me was to submit the same issue but against a different product group. Unfortunately it looks like that avenue is currently closed (see Internet Explorer feedback site)

As someone who has spent time giving you feedback that I feel will help make your overall product better, I find it a little shocking that you ask for me to commit even more time even though I do not feel like we have made any more progress to fixing the problem. I can understand your desire to ensure issues are properly classified so the appropriate team may address it, but I feel I do not need to be involved with your company’s strategy at issue resolution since I feel you have all the information you need.

I appreciate your constant correspondence to my submitted issue, but I think I would have had a much better experience had the person who closed my issue, reclassified, or even duplicated the issue for the correct team to ensure that continued progress is made on the issue. I don’t understand why I need to spend additional time iterating the same information I have already provided your company with.

I am happy to discuss more of my experience submitting feedback and my own personal thoughts on how the user experience could be better. I do encourage you to contact me (emailpat “at” thekua.com) as I will be happy to share more of my thoughts to help improve the experience.

Yours truly,

Patrick Kua

Argos Uses Websphere

I’m not sure what makes it difficult people putting in a DNS entry so that [somesite].com redirects to www.[somesite].com. I hit Argos yesterday only to find out that apparently they use Websphere. That’s all very nice to know as a techie, but as a customer, it’s not quite the user experience I want.

Argos and Websphere

© 2017 patkua@work

Theme by Anders NorenUp ↑