UX designer for two days

Over the last few years I’ve always worked with UX designers, but I had never tried being one for two days. I had my chance last week when I was part of a “design pressure cooker” with a mission to make our app “simpler” and to enable our users to work together on lists. I cannot go into the specifics of our app and the solutions we designed because I think my client wouldn’t want that information public yet. But don’t stop reading yet! I have plenty of fun observations to share.

If there’s one lesson I’ve learned from being a UX designer for two days, it’s that it’s not simple to design something simple.

I’ll get into more detail about why that was. I also want to go over how this workshop helped people from different roles empathise with what it’s like to be a UX designer. Lastly, I’ll discuss how communication styles can help or hinder a creative workshop.

What’s a “design pressure cooker”?

I cannot assume you know what a design pressure cooker is; I had never attended one either. In our context, it means that the business gives us a problem they want to solve and we have to come up with a concrete solution with User Stories and sketched-up user flows. Sometimes these pressure cookers last a week, but now we only had two days.

There were different roles present. Two product owners, the UX director, the UX designer from our team, a backend developer, two mobile developers, a frontend (web) developer, me (tester) and two visual designers. This group wasn’t fixed for the duration of the two days, especially the product owners and UX director had other tasks to do and would join us every now and again. It was the first time a tester was present. I had asked to be invited because I wanted to know whether it would be useful to have a tester role present and because I personally wanted to see what this was like (regardless of my role).

We kicked off the event with everyone present and a description of the problem. After the problem was described broadly, we all brainstormed ideas of how we could solve it (we were diverging, to speak in BDD terms).

During this part, I had a couple of observations. The developers were having a hard time doing this. They were used to being given a specific problem and using the existing system to design and implement a technical solution. Almost never does the software development team get to be involved in the creative process of letting “the system” go and go beyond it with out of the box thinking. It was like a dormant part of their brain had to wake up and suddenly do something. They were very uncomfortable letting go of what they knew about the system and the technical boundaries. As a tester, I shared a similar fate with regards to what I knew about the system and I knew that some of the solutions I thought of would not be possible yet with our current architecture. But I made a choice to ignore that and it actually felt very freeing. I was free to let my feelings guide me and not the system. I could truly place myself in the users’ shoes and what they would want. Of course, I made a lot of assumptions in the process, but even that could be let go for now. Ahh, how lovely.

After brainstorming individually, we presented our ideas and with dot-voting, we chose a winning concept that we would then design in more detail. This whole process of explaining, brainstorming and presenting already took hours; the first day was almost over. Now that we had a winning concept (we converged), it was time to go back into our familiar system-thinking and how it could be made possible. Now, I noticed that people were getting more into the ‘but….’-mindset. The talk of feelings was over, we were back in reality and a more familiar terrain for developers. I struggled with this part more, on a personal level. The atmosphere changed from an ‘everything is possible’ kind of mood to ‘I can kill this idea with a lot of objections’ kind of mood.

Day 2

For the sake of the length of the blog post, I’ll skip to day 2 of the session. The developers weren’t attending anymore because we were going to sketch up user flows of our idea. Even though we had one main idea, it still contained more than one user flow and problem to solve. We split up into teams of two. At first, I was working with the UX designer and that was hard. We had completely different styles of working. I like to stick to the core point and quickly get something drawn on paper and then think of all the alternative paths, problems and questions we need to answer. The UX’er was immediately stuck on point one in the user flow because she only saw problems and choices. To me, it felt like we didn’t have progress, to her it felt like these questions needed answers now. It frustrated me and it frustrated the UX director (who was working with us when he was in the room). It felt like the conversation couldn’t progress forward.

 

We never stuck to the point in a conversation and it quickly derailed into a totally different place. The thing is, it’s not like her questions were invalid, she raised good points. But in the context of our mission (make a broad solution) it was out of place and kind of exasperating. This is when I thought “sheesh, designing something simple isn’t simple!”. Not only because of the design itself but because people with all their different views and feelings and needs have to work together. And then there are the limitations of the system.

After the lunch break, I partnered up with the visual designer. Our working styles were much more alike and it felt satisfying to make some progress. It was magical to see him work quickly in Sketch and we drew up a couple of user flows. Sure, we still had unanswered questions and we made some choices that might be reversed later, but we had something to show. When something is visual, I think it’s a lot easier to discuss it.

It was Friday afternoon and slowly our creative juices started to run out. It was time to wrap up the session, and it’s also time to wrap up this blog post. I saw some parallels between the UX role and the tester role. Even if you don’t have a UX role you can still have lots of great input, same goes for testing. A lot of it is using your common sense. In our ‘circles’ (software development), we all have used a lot of apps and programs. We know when the UX sucks and we can bring that experience to the table. We know when an app sucks and then we bring test ideas to our own project. Experience counts for a lot.

I also liked having different roles present at this session, even though the developers left after the first day. I do think they have more empathy for the designers now that they really had to try and think like a designer themselves. It’s a totally different way of creative thinking than programming.

Thanks for reading!

PS: An extra note on designing something simple. On Twitter, Joris Meerts wondered what is needed to design something simple: experience, restraint, pragmatism, thoughtfulness, rigidity? Ruud Cox added: perseverance and James Thomas added: confidence.

I can’t claim to be an expert after only two days, but what I noticed was that restraint is needed. It’s very easy to let the options explode, even when you are confronted with just one business problem. If you don’t restrain yourself to explore only a couple and quickly weed out dead ends, you’re going to have a hard time. A bit of rigidity is needed, even in a creative process. Perseverance is also needed. Creative thinking needs time. Sometimes you’re tired, out of ideas, but you take a break and go on. You talk, discuss and brainstorm with other people until you get to something good.

PPS: I didn’t want to burden people in the session with frameworks, but Cynefin was relevant here, I think. People sometimes felt that we were solving a problem that was already solved, but it wasn’t true. I think they were in the ‘obvious’ domain in their head, but all the evidence suggested that we were dealing with a complicated problem. Yes, the problem has been solved by other apps so we don’t have to invent the wheel. The technical side of the problem moved us into the complex domain, as we are dealing with many layers of the system and part of it is quite old and hard to change.