DESIGNING IN THE REAL WORLD
A CASE STUDY
Every designer dreams of bringing forth an app feature, or a stunning masterpiece of cloud software, or a game that goes viral overnight. It is mandatory to dream. Great ideas are born when a designer gets lost in the creative stratosphere.
And then there is reality, where designers do the work. There are limiting budgets and timelines to contend with, stakeholder goals that don’t always align with user goals. Sometimes—in the case of start-ups—it is a matter of surviving (fingers crossed) just one more month.
It is a matter of finding the balance between the two. In the end, a designer does their part to create a product that will be sold and that will generate revenue for a business. Simultaneously, a designer acts as a liaison between the business and customers, and must ensure that the product solves a problem and adds value to a user’s life.
Ultimately, this is a problem that every designer must know how to navigate.
The following is a breakdown of a recent challenge I encountered in my current position at HiveTracks, which can shed light on how to go about trimming a user-driven design down to a lean MVP that meets budget constraints. While I cannot disclose precise details about the software itself, my goal is to highlight the overall process of what UX/UI design looks like in the real world and lessons learned.
WHAT USERS WANT
(UX RESEARCH)
Through feedback from our live mobile beekeeping app, we were able to divide our user base into hobbyists beekeepers who have only a single or small number of hives and professional/ sideliner beekeepers who manage multiple apiaries and up to hundreds of hives. For those who fell into the latter category, I began setting up interviews to pinpoint how the hobbyist-centered mobile app fell short of their needs for running their everyday beekeeping operations.
As a designer, I needed to hone in on what data points were most important for them to know, what data they recorded when visiting their apiaries, and what data they needed in terms of running a successful business. Our founder is a beekeeper, so he’s always a great resource, but it’s imperative to talk to others outside our business to get a true understanding of the problems we’re trying to solve.
DESIGN PROCESS
Building upon a previous beekeeping web application that I originally designed and prototype-tested for the Lebanese government (a means to easily monitor the health of beehives and communicate with beekeepers across the entire country), I made some tweaks based upon the information gathered from informational interviews with professional beekeepers.
It was a good foundation to work from, although I really wanted to do more testing on it before we started development. The reality was, however, that HiveTracks did not have time for more testing and iterations—we had to get the web app developed and launched by the 2023 beekeeping season, which was only 2 months away.
HANDING OVER THE DESIGNS TO THE DEVELOPER
The developer set out to implement my designs, like he had with the corresponding mobile app.
However, he soon realized that in order to meet the deadline, a different solution was needed. Using an “out of the box” database framework, he was able to connect our database with a sparse front-end that allowed for searching and filtering apiaries, hives, beekeepers, beekeeping records and pinpointing health issues.
It wasn’t elegant—it wasn’t even remotely pretty—but it was functional. It did what it was supposed to do: act as a means for retrieving beekeeping data for professional beekeepers.
What was hard for me as a designer was that I saw all of the UX flaws that were introduced in shifting from my tested designs to an entirely different design altogether that didn’t put the beekeeper at the center of the application.
In the end it was ultimately an MVP, and we had to go with it.
My original design (top) and what was developed (bottom).
FEEDBACK SESSIONS
We gave any professional beekeepers in our customer base who wanted to try the new web app free access to it in exchange for his or her feedback.
I scheduled 1-on-1 Zoom sessions with the web app beta testers and began compiling a lengthy spreadsheet documenting feedback from each user and categorizing and prioritizing that feedback to use as a roadmap for future iterations.
Thankfully, people are honest and not afraid to share their opinions or ideas. No matter what, honest feedback is what you need. But in all honesty, there were some brutal feedback sessions. Some users ripped the web app to pieces.
We had to come to the uncomfortable understanding that in rushing to release the product, we ended up putting a very under-cooked version out into the world.
As a UX/UI designer, I was dying—I didn’t want our customers to think that I’d designed the “out of the box” database that some found confusing and frustrating. But I had to shut my ego down and listen. Ask questions. Listen some more. This was a crucial learning opportunity.
In the end, there were a handful of MVP testers who understood our vision and wanted us to help build it. So we partnered up with those beekeeping businesses and started working toward a more sophisticated version.
BACK TO THE DRAWING BOARD
After numerous additional Zoom calls with our small group of testers, we were very confident in what we needed to build in order to meet their needs as beekeepers and business owners.
Knowing that our budget was very slim and that our developer was managing multiple projects, my initial iterative designs built upon the current “out of the box” MVP. I had my list of prioritized changes, tackled the top problems, and created streamlined solutions.
I fixed the top UX issues (improving user flows, consolidating data spread out in multiple places, adding buttons that seemed to be missing), reorganized the architecture, and reduced the number of tabs in half, from 10 to 5, which made for a much more streamlined user-experience.
I felt confident that the developer could handle these changes efficiently according to our deadlines and that we could make these changes within our limited budget, and that—most importantly—it improved the user experience…
LIVE MVP VERSION
REDESIGN
BUT WAIT…
However, when I presented the re-design to the CEO, he found it to be…well, bleak. While it solved some key problems, it wasn’t what we wanted to build at all. This was not the product we dreamed about and envisioned. Instead, he told me to start over and design the web app the way we wanted it to be and the way users needed it to be.
As you can imagine, I was thrilled.
That’s not to say that I threw it all out the window—I didn’t. I retained some of the key functionality the developer had already built out, and instead focused on making sure that the new design addressed all of the crucial problems the MVP did not. In other words, I redesigned it by making the beekeeper as the heart of the design, as I’d wanted to from the beginning. And I made it look pretty.
When the CEO, founder, users, and I were happy with the designs, we passed them over to the developer…
Updated design with more engaging UI.
REALITY CHECK
Are you expecting a happy ending? Sorry. Don’t mean to crush your spirits, but reality is tough.
What did happen was that the developer told us matter-of-factly that the new designs were going to take a lot of time and a lot of money. We didn’t have either.
THE COMPROMISE
With the developer, we worked to figure out what elements of the designs were “doable” and which were “big lifts” when it came to the UI. We held off on some of the UI choices.
We also divided the designs into changes that were “pain relievers” (assuaged user pain points) and those that were “vitamins” (boosted the user-experience, but weren’t fundamental).
Like any other creative project – we edited. We snipped out entire features that we didn’t need right now. We scaled back the designs to less enticing displays of information, but without sacrificing the quality of that information. And we ran each screen past our developer and his project manager.
We compromised. We came up with a realistic solution for where we are now, and also had a blueprint for what we eventually want the product to be. And by scaling back many things, we were able to pick one new feature to add and develop, which will be a game-changer for beekeeping businesses and for HiveTracks.
It’s a work-in-progress and, realistically, that’s okay.
LESSONS LEARNED
1
I learned that it’s okay to dream. Start big with your designs, and then work backward if you have the means to do so. It was an exercise in prioritization, sorting out “pain relievers” and “vitamins,” and helping to create a “finish line” to work toward, one iteration at a time
2
Early collaboration with developers is key. Involve the developer early on – with each screen. Both the CEO and I learned that the developer should always be part of the process early on – if schedules are hectic, find a way to make time for design feedback sessions.
3
Progress comes from compromise. The developer will come up with a different solution than the UX Designer. Programmers typically don’t think from the users point of view; they approach building apps with what is easiest and fastest to implement. Designers focus so much on what the users and their stakeholders want, they don’t stop to think how complicated their design solutions could be for a developer (especially a solo developer!). Instead, both the developer and the designer have to work together to create an Option C that finds the best of both worlds.
4
Deal with your ego as a designer. Maybe you want to show up to a party wearing a Rolex, designer clothes, and driving a Maserati, but you end up having to settle for a Timex, a nice Target outfit, and rolling up in a Honda. In our case, we showed up on an unwieldy bicycle wearing ill-fitting hand-me-downs. The point is: have the courage to show up, connect, gain insights, and just live in what might feel like some excruciating imperfection. You’ll survive. And your design work will have a very strong foundation with which to improve. It’s not about you. It’s about the product.
5
Don’t be afraid of imperfections. While it is important to do your best as a UX designer in terms of user-friendliness and prototype testing, the first developed product might start off pretty rough. Rest assured, the first version doesn’t have to be pretty - the MVP just has to be a working prototype to get feedback among a select group of users. It is a tool for learning.