In which UX process actually works, and I am surprised

In the past month or so of working on projects with the Student Devs I’ve had a chance to use some of the methods I’ve read about, and in almost every case, I’ve come away impressed by how these methods are actually really useful.

Prototype screens
Screens for a clickthrough prototype I made this week.

Because I’m still relatively new to UX (to compare, I’ve been serious about illustration for over five years now), I run into a lot of firsts these days while working on projects. First guerilla user test! First stakeholder interview! First user journey! What’s been really enlightening – and humbling – has been understanding the utility of tools and methods that I previously thought of as kind of pointless.

I’ve been reading about user-centered design since discovering it shortly before coming to college, but I’ll admit that a lot of it always seemed…silly? obvious? overhyped? to me. A lot of UX techniques are very straightforward. Write down all the different sections of your site and organize them into logical groups. Make simpler versions to test first before investing hours into a high-fidelity prototype. They always seemed too mountain-of-a-molehill, too formalized, too much like Process with a capital “P”.

Well, I guess now I’ve learnt to not knock it till I try it – in the past month or so of working on projects with the Student Devs I’ve had a chance to use some of the methods I’ve read about, and in almost every case, I’ve come away impressed by how these methods are actually really useful.

For example, as a fun side project, Thomas and I are making an app that helps students shop more efficiently at the school snack store. I decided to try making a user journey for how students currently interact with the store – it would help identify ways our app could be more broadly useful than the simple initial idea, but I also did it in large part because I felt like that was what “real” designers did: go through Real Designer Processes. So I went through the process.

I felt very silly going in, writing down every step the student went through, I was also unsure of whether I was doing things correctly. There are tons of templates for user journeys online, all slightly different, all slightly confusing. In the end I decided to grab a random set of useful-looking attributes from the templates and made my own. Our imaginary persona was Hungry Bob, a student who had missed lunch due to a meeting with a professor that ran long. Hungry Bob was then brutally subjected to every stressful experience possible within the snack store: public shame, long queues, confusion about prices, not enough time to browse, hard-to-find items – all the while contending with gnawing hunger. To be honest, I thought it was a little over-the-top…so it was both reassuring and worrying that when I showed the completed user journey to Thomas, his first comment was “wow, that’s exactly what happens at [store name] all the time”.

By really getting into Hungry Bob’s mindset, reflecting on our own frustrating experiences at the snack store, and examining each step of the process in detail, I was able to come up with a few suggestions and refinements to the original idea that I wouldn’t have thought of before. For instance, we originally had your in-app cash balance hardcoded to be $8, since that’s the amount students are left with on their cards if they don’t use it on lunch. But while thinking about how students actually hunt through the overpriced items at said store trying to find a way to maximize the lunch money, I realized that people often don’t mind paying slightly more than $8 if it allows them to get a few items that they really want, instead of an item they really want and disappointing filler items like carrot sticks or something. (Sorry, carrot-lovers.) I feel somewhat sheepish that it took creating a user journey to realize this, but hey, at least we saw it, and now our app has a flexible lunch money limit. It’s a very, very simple change in the code, but it makes the app much more useful to students – at least, I think it will. We haven’t gotten to the user testing stage yet.

I’ve also had a chance to see the emotional use of prototyping beyond its obvious “let your clients complain about something before you spend weeks building it” purpose. This week has seen me creating a mid-fidelity mobile prototype for an app the Yale College Council requested, using InVision (which I’m happy to plug here because they gave me a free student subscription, and because it’s really an amazing tool). The councillors handling the project on their end have been really happy with the ability to play with an intermediate prototype, instead of crossing their fingers and hoping that we deliver something that they like, and we’ve been talking about changes they’d like to see.

What’s cooler in my opinion is what happened with the snack store app. On Friday last week we took the idea to some managers within Yale Dining, to ask if they’d be okay with us making it, to see what their broader goals were, and to ask for access to their data. I think doing the user journey gave us some useful specific student experiences that we could refer to during the meeting to make our arguments more compelling. Would we have been able to bring them up without doing the user journey? Yes, but having mentally walked through the store earlier helped make certain oft-overlooked points much more salient.

Anyway, our meeting was going on, and we were encountering some resistance to our idea – one of them didn’t think it was particularly useful, and was much more enthusiastic about the prospect of us (implementing? customizing?) a third-party service that did something else entirely. More than half an hour in, one of the managers was starting to get the utility of our idea, and I felt like this was a good time to lock in his support. We hadn’t planned on showing the very basic prototype that Thomas had made over fall break, since it’s a plain text-based app with a couple of hardcoded values that doesn’t really do much – we didn’t think it would help our case. But by this point in the meeting I’d figured that we needed all the help we could get in communicating our idea, so I got Thomas to pull up the prototype on his phone.

That was probably the most interesting mood transition I’ve ever seen in a meeting. (Thomas says he couldn’t detect it, but I’ll believe it was there.) Both managers got more interested immediately, leaning in, expressions changing, becoming more curious. Once there was a working – even minimally – prototype on that conference table, they got much more engaged, playing with our four hardcoded snacks, adding and removing items from the cart, testing the autocomplete. It was easy to see that our previous descriptions of the app had been too nebulous, not compelling enough – probably due to our inexperience with meetings and pitches – and that now they really understood what we were going for. After that it was an easy sell. I was really impressed. I mean, you read about this kind of stuff, and about how Processes/tools are supposed to “disrupt client engagement” or whatever Markov-chain buzzword is in fashion today, but seeing it work in person is something else.

So. Yeah. That’s been really neat. I’m enjoying being a designer and giving myself permission to work on design and only design: I kind of wish I had more to do with the programming bits, but I know there aren’t enough hours in my life for me to do that many things well. Besides, I’m making a MUD game, and writing specs and code for that is using up most of my programming time.