Tales of a UX Designer in a Dev Shop

I wonder how many designers, after reading the title of this post, thought of a perfect meme to describe how that scenario plays out. I mean, even though we all know that working with brilliant developers who can bring your most precious ideas to life is the dream, we also expect that the designer-developer relationship won’t be filled with rainbows and unicorns.

Last summer, when I was thinking of joining DevFacto as a UX consultant, not only did I picture those memes too, I was also unsure if this type of challenge was going to be a good fit for me. Could I picture myself debating which features matter and which ones don’t, every single day? Hmm…

Luckily, soon after coming on board, I got to meet the developers over beers and got a true sense of the personalities on the team. The excitement of collaborating with brilliant minds quickly grew on me and I looked forward to learning within a fun, supportive culture. Now, six months into being a DevFactonian, I can report that I’ve learned a few lessons and busted some myths about the relationships between UX designers and developers. Here are my top 3 discoveries:

1. Developers attach to their work as if it were a baby (just as much as designers do)

Whether in a dev shop, or a design studio, we all protect what we create, foster and put effort into making. So, when someone else modifies our work in any way, it’s difficult to detach oneself but very easy to discount any modification as a nonsensical idea.

Whenever that happens, it helps to remember that we are all in this together and we share the same goal – make the best solution possible. Or, as I like to think about it, create “the perfect baby.” In each project, we all contribute from our own experiences to build a product that combines a fresh, sleek look with exceptional functionality. However, ultimately, we do this not to appease our own egos but to create value for the people who will be using what we’ve built.

2. Sharing your process promotes collaboration

After talking to one of our brilliant devs, I realized that effective collaboration is all about sharing the process. The developers write code, make something come to life, and it either works or it doesn’t. In that way, the mind of a developer is binary. Meanwhile, as designers, it is our job to come up with various ways to create success (usually there are many) and put forward the best one in a mockup or a prototype. However, sometimes we fail to share how we arrived at the presented solution. This makes it hard for a developer to understand why we are making certain suggestions and can lead to a rejection of the idea.

Collaboration comes from having a common understanding of a problem.

Therefore, sharing both my approach and context helps them see where I’m coming from and take my modifications as potential improvements, rather than just self-preference edits.

3. Feelings matter

Even if we try our best to be rational and logical, at times it can be hard to accomplish. As software users, we respond to emotions, we make mistakes and get distracted. We like or dislike things based on how they feel, even if that sentiment makes no sense. That’s just how we’re wired. Even though we’re trained to think differently, it is still easy for us to fall into certain patterns and behaviours quickly.

It’s easy to forget we’re all just human and that does not make us the ideal user.

Empathy has been THE card up my sleeve as a UX designer. I use it both internally with our project teams and externally with our clients. In my work, I’ve learned to play that card as much as possible for the sole purpose of creating products so easy to use, that people will want to use them more.

I do know for certain, that there are still many lessons to be learned and plenty of discoveries to be made about the process of designing user-centric software solutions. But one thing I can attest is that despite the left-brain and right-brain differences between designers and developers, the awareness of the value of good user experience goes well beyond our roles.

Thinking Like a User

Pitfalls of self-referential design

Building software that’s easy to use and intuitive is a tough task to say the least. As developers and designers, when we set out to create software that humans will love using, we need to take our individual opinions out the equation as much as possible. This task, however, is easier said than done; thinking like a user is a skill that needs constant practice and consideration.

Self-referential design is one of the greatest risks to a successful software project. The professionals developing and designing the solution and the companies we are building for, each have their specific point-of-view and personal preferences. Although these individual biases are based on extensive professional experience, they often yield software designed for the creators themselves rather than the end-users.

At DevFacto, we are constantly looking for new and effective ways to design user-centric software. One of the guiding schools of thought in this area started at Cooper in the early 1990s, when design methodologies were for the first time applied in the world of software development. Amongst the best-known ideas introduced by Cooper is Design Thinking – a human-centered design process for creative problem solving, now widely used by tech giants such as Google and Apple. So, when our UX team got the opportunity to attend Cooper’s Immersive Design Thinking workshop we were beyond thrilled!

Design thinking concept in user-centric software design

User journey doesn’t always end in success. Design Thinking helps us build software humans love to use.

Approaching user-centric software development

This past summer, a group of four DevFactonians consisting of Business Analysts and UX Designers, were lucky enough to take part in a three-day long Cooper training course in San Francisco, a city brimming with unique architecture and distinctive people. If there’s a center for creative thinking in the world, that could very well be it, making the location a perfect setting for a Design Thinking workshop.

From day one, we dove head first into the program exploring the latest techniques and best practices in human-centered design. Through creative exploration, we learned powerful ways to identify and solve almost any design challenge. One of my key takeaways was a realization that identifying the real problems can be very enlightening, especially when faced with how our presumptions change as we learn new information. By following the Design Thinking process, we shine a light on the various points-of-view of the different users, which affords us a chance to build empathy and plot a course that respects their goals and pains.

Over the three days of training, we ran various exercises to help understand and clearly define the problem we were tasked to solve. Starting with planning and conducting research interviews, through generating insights from user research, to using exploration and storytelling in creating concepts that address the goals of both businesses and consumers, each of these exercises built on the previous and helped us remove assumptions by focusing on finding new and interesting things to consider. Once we uncovered the real problems, we learned how to work on effective solutions through modeling, ideation, and prototyping.

During the training we were tasked with conceptualizing a new photography product or service. The solutions we and others there came up with surprised and delighted us in their creativity and uniqueness. Many of us had ideas that changed significantly through the process as we learned new information. Overall, we discovered the importance and power of careful research and thoughtful planning.

Benefits of the Design Thinking Immersive training

Traveling to take the Design Thinking Immersive course was in many ways an enriching experience. In addition to our new understanding and skills, the four of us grew closer as a UX team by working together to solve challenges creatively. Since returning from San Francisco, we have all been able to incorporate the new knowledge into our work, making a positive impact on our respective projects. Most importantly, by applying the principles we’ve learned about through Cooper, we have not only grown as designers, but we have also elevated he experiences of the users who interact daily with the software we build.

UX Heuristics: What the Heck is a Heuristic, Anyways?

Wikipedia defines heuristics as “strategies using readily accessible, though loosely applicable, information to control problem solving” . The origin of the word itself lies in curiosity and inquiry. In user experience design, this means applying a specific set of common principles to uncover problems and identify areas for improvement. At DevFacto, we use them to evaluate, facilitate, and in some cases predict the strength, quality, and effectiveness our work. Read more

Effective Business Analysis Pt 1: Why and Who

Business analysis (BA) is key to delivering quality software–not just something reliable with a low defect count, but fit-for-purpose, valuable software. Effective BA results in a functional design that incorporates business improvement that goes beyond stakeholders’ requests. In this two-part blog post, we’ll look at what makes BA effective. Read more

The Value in Speaking the Right Language

It can take professionals a few years to find their voice. Younger developers often don’t have the experience or the confidence to speak at a conference, let alone guide a room of stakeholders through the complex process of building an application. Read more

Live Sketchnoting @ UX Camp YEG

I was asked to live sketchnote UX Camp, a day of user experience presentations put on by UX Edmonton. Having sketchnoted UX Camp last year, as well as events like ‘Reimagining Shaw Conference Centre’ recently, my acceptance of invitations like this is pretty quick now. It is fast becoming something I love doing, regardless of the stress involved in drawing at speed in front of a large group of people. Read more

The Art of Sketchnoting

Everyone can do it

I used to take notes in school, but they didn’t look like this. Well, maybe the margins did. Read more