Empathy for engineers — a case study and conversation on collaboration
Learning to understand and empathize with the talented people who build digital products
Our UX team recently completed a short design sprint in conjunction with a team of software engineers. The goals of the exercise were to develop communication skills and encourage collaboration between the UX and engineering departments. We spent a week designing and building out a responsive website based off of a provided persona and problem statement.
My role for this project was UX Designer while working in tandem with my teammate Carly. We worked together with three software engineers, Demry, Linda, and Kyan.
THE CHALLENGE — UNDERSTANDING ONE ANOTHER’S PAIN POINTS
This project wasn’t just about applying design thinking to a problem space. The key takeaways were understanding how to work with engineers. As a UX designer, I was curious how they creatively solved problems, viewed the feasibility of our designs, and how they broke down projects and divided up responsibilities in order to hit deadlines.
Here is a timeline of our project(all completed with our software engineers unless noted):
- As a team we received a user persona and problem statement that had been synthesized from prior research
- Using sketching, we ideated on possible concepts, listing out potential features to solve our users problem
- Utilized the MoSCoW mapping method to prioritize features.
- Wrote out steps for a potential user flow
- Conducted a design studio on steps for the user flow
- Identified a primary page for the developers to build (due to time constraints they were only tasked to build out a single page)
- Conduct usability testing using paper prototypes
- Review results from usability tests and align on any updates to page that will be developed
- [UX Team Only] Design up to hi-fidelity mock ups and prep for hand off to engineers via Zeplin
- [Engineering Team Only] Code out a single flow from hi-fi designs.
- Present and walkthrough final designs.
At the conclusion of the project, I touched base with Demry and asked him open ended questions about his experience working through this project with a UX team. I felt this case study was an opportunity to hear an engineers voice in understanding how they viewed the experience.
PERSONA AND PROBLEM STATEMENT
To reiterate, the persona and problem statement was provided to our team as part of the exercise.
Amanda enjoys cooking with her partner, friends and family. She keeps recipes that she likes so she can make them again, using store-bought groceries and sometimes making modifications.
Amanda needs to use the ingredients in her fridge because it’s convenient and cheaper than going out and buying specific ingredients.
How might we make it easier for her to use recipes that require items she already has?
SKETCHING — CONCEPT GENERATION
As a team, we sketched out possible design solutions for our persona. To encourage the software engineers, we started out the exercise by having everyone quickly draw 3 bad ideas followed by 3 good ideas. The engineers initially looked a bit lost, then felt incredibly pressured by the fact that each sketching exercise was closely timed.
From Demry,
The experience itself could be summed up as eye-opening.
I think the consensus of most software developers is that they, as developers, are working on more rigorous, logic-heavy, and all-around denser material. However, this experience with the design studio's sketching process, particularly the "time-blocked" sketching…demonstrated the intensity and complexity of an effective design process.
I really enjoyed Demry’s open minded approach to learning about our process. It’s easy for UX teams and developers to put up emotional barriers and assume that their team is handling the majority of the work and pressure for a project. Collaborations like this really shine a light on the merits of communicating and working alongside other departments to build empathy for one another.
Sketching was a great way to break in the group and get the creativity flowing. It helped the engineers begin to understand our process as designers. Starting with a pen and paper, so far removed from any keyboard or code, helped them get an idea of how every design feature was thought out in a thorough way.
FEATURE PRIORITIZING — MoSCoW Mapping
From the sketching concept generation, our team came away with a number of features that could potentially solve our users problem. With the engineers, we brought them through our process of prioritizing which features to build out in our user flow.
The most striking thing in doing a MoSCoW map with engineers was their immediate focus on feasibility in coding certain features out. Truth be told, the persona and her problems were almost immediately lost in the fray. As UX Designers, my teammate and I guided the conversation back towards focusing on what features were most important in addressing our users needs:
- Simple recipes that take less then an hour
- A way to use ingredients she already has in her fridge
- Recipes that can be customized depending on her appetite or current ingredients
Our team ultimately settled on the following ‘must’ features for our MVP:
- Recipe generator
- A visual way to show the total prep/cook time for a recipe (research showed recipes that took under an hour were ideal)
- Input form where she can enter ingredients she currently has
Demry, in commenting on our MoSCoW method,
I thought it was reminiscent of our prioritization matrix, except in many ways, primarily the constant reordering (which requires conversation and long-term thinking about the project), it was more complex!
I found this to be a recurring theme throughout our project, that engineers tend to think of designs in terms of effort and feasibility. Encouraging the engineers to be vocal about design solutions while prioritizing helped us to understand the impact our decisions would have as UX designers. It’s important to constantly remind all stakeholders in a project of the following:
Why does this work well for the user based on what we know?
In short, it was important to communicate that we were going to need this recipe generator feature even if it required additional effort in the engineering department because we know it will solve the users problems.
DESIGN STUDIO — NAVIGATING THE FLOW
With out features clearly defined, we got another ream of paper and set out on sketching out the user flow. Our engineers, now warmed up to the idea of sketching, were loose and open to drawing out different ideas.
The above rough sketch was refined and built out into a paper prototype which clearly laid out our flow.
USABILITY TESTING — DOES IT EVEN WORK?
Using this paper prototypes, we conducted 1 round of usability testing with 3 participants. We were confident our flow was simple and with our engineers in tow, we tested this out.
Task: Find a recipe that uses green peppers, garlic, and chicken that takes under an hour to cook
We found that users were able to complete our task without any major issues. Due to the time constraints of the project, we opted not to make any major changes when designing up to our hi-fidelity prototype for handoff.
Demry in commenting on the usability testing,
The data received from this type of testing is extremely useful, and paramount to creating a good application and design. Customers know best, and this usability testing demonstrated just that.
It was great to see that Demry and our engineers saw the value of usability testing. We still hadn’t touched a keyboard and had already gained a ton of value from our sketches and usability results. The idea here was that by showing them all the steps in our process, the engineers would fully understand the reasoning behind the design decisions and resulting work involved.
DESIGNING UP TO HI-FIDELITY
Under normal circumstances, we would have built out mid-fidelity wireframes and conducted additional testings to further validate our design decisions. For the sake of this exercise and time, we selected one screen for the developers to build out and proceeded to design high fidelity mock ups of this single screen.
Our developers expressed interest in designing the ingredient input screen which would in turn generate a recipe (which in reality was a multi-screen flow). The developers like the challenge of having the ingredients populate the screen while narrowing down or generating additional recipes depending on what was added.
Again, our user likes to be creative and often times had different items in their fridge, so this feature allows them to improvise recipes.
DESIGN HANDOFF
Using Zeplin, we were able to walk our engineers through our hi-fidelity designs. The engineers were also able to access our Zeplin file, which allowed them to inspect elements at their leisure.
Zeplin allowed our engineering team to see our exact designs and match them accordingly so that no pixels were lost in the handoff.
I was curious at this point at to how our engineers would break out this project. Demry was able to shed some light on this,
The general criteria for “who takes what” is the individual that thinks they can perform the job most efficiently, that is, fastest and most accurately.
Linda clearly excels on back-end logic, Kyan and I had a toss-up for the front-end, and ended up working on it together, as we both could use more experience with CSS.
What resonated for me was that the engineers had a process as well, a method to break things out and tackle our designs to the best of their abilities.
CODING THINGS OUT
I spent some time sitting with our development team while they coded. The experience was rewarding and definitely helped in understanding their work. In going back to our feature prioritization, our developers mentioned utilizing and API to help build out our recipe generator. The idea was to draw from an existing recipe database rather then hard coding in recipes.
Edamam, a free recipe search API made sense for our quick exercise. It offered users the ability to input multiple ingredients and refine their search based on time and other factors. Time was the most important for our team as our user needed recipes that were under an hour to cook.
I specifically asked Demry about major issues the engineering team encountered because I was curious what they struggled with most in our designs.
The CSS was honestly the trickiest part. We even had our supervisor looking over a portion of the code, and helping us for 30 minutes on moving some letters down a few pixels. It happens.
30 minutes for a few pixels, phew. I think it’s super important as a designer to understand the impact design changes can have. As designers, we move a text box a few pixels in a matter of seconds but the impact this can have on the development side can be monumental.
FINAL DESIGNS
KEY TAKEAWAYS
I really enjoyed hearing Demry’s thoughts on this experience as a whole,
I learned the importance of working before working. That is, sketching, planning, drawing, and just how much you can learn in the process of preparing.
Sun Tzu says something to the effect of “a victor must plan effectively and change decisively,” and I feel this principle was held up by the UX team.
Plan effectively and change decisively
I love that attitude in a developer.
To a certain extent, after going through a design iteration, whether it be a two week sprint or 10 month re-design, you want to know your hard work is being treated respectfully and your decisions are being honored when you hand off designs and research insights.
A key takeaway from this experience was building trust with the engineering team, having them understand our process and work ethic while in turn understanding theirs. That way, when they start to code there is empathy behind their work, allowing them to move forward confidently.
