- Noah Jacobs Blog
- Posts
- On UI/UX
On UI/UX
Or how working on UI/UX is like going from cooking eggs scrambled to sunny side up (with cheese)
On UI/UX
Or how working on UI/UX is like going from cooking eggs scrambled to sunny side up (with cheese)
XLVII
2024.05.19
I never thought in a million years I would be focusing on User Interface / User Experience (UI/UX) for any reason whatsoever. Now, it has emerged as one of the most pressing things for me and the team at Ultima to work on.
A cool way to look at it is that as the complexity of something increases, so do the variety of the problems it brings.
Cooking Breakfast
Starting broadly, as something gets more complex, how you handle it tends to get more complex, too.
If you are cooking scrambled eggs with butter in a pan, there aren’t a whole lot of variables. You have to deal with how hot you make the burner, how long you let the pan sit on the burner before adding the eggs, how much butter you use, how often you move the eggs around in the pan, and when you remove the eggs from the pan. That’s 5 not so consequential variables.
Now, if you’re cooking sunny side up eggs with cheese and seasonings, the complexity goes up a bit. You have these new questions:
How much cheese do you apply and when?
How much seasoning do you apply and when?
How crispy do you want the bottom to be AND how runny do you want the top to be?
How do you implement some mix of spatula work and possibly a pan cover to get the above outcome?
The last two points are something that are admittedly kind of challenging to figure out, and really are variables on a whole new axis compared to what you were dealing with when making scrambled eggs. You want the scrambled eggs to be homogeneous, all the way through. Sunny side up eggs have different qualities you’re going for in different places.
This is a cartoon example, but it illustrates a point:
"The complexity of the controlling system must be at least as great as the complexity of the system it is controlling."
Add more things that could go wrong to the mix and you need to be more responsive. It’ll get even harder if you add in cooked potatoes and a cappuccino to the breakfast; these introduce entire new variable sets.
What’s more, if you want to build a system that you can walk away from in an environment like this, you need the system itself to be more complex. While one talented person can cook a breakfast with exceptional sunny side up eggs, sautéed spinach, potatoes, and a cappuccino, to do that a bunch of times every morning and also allow for someone to order avocado toast, you’re going to need a team with a pretty efficient team.
As the complexity and scale of the operation goes up, so to should the complexity of the system governing it.
And, if you’re curious about how you can objectively measure “complexity,” there are a few different posited answers to it in different fields; two that come to mind are the Assembly Index and Cyclomatic Complexity. The former is controversial and the latter is used in practice.
Business Complexity
In the most fledgling state of Ultima’s sales intelligence endeavors, the complexity was insanely low. We would talk with sales people on the phone, listen to their problems, find information that might solve those problems, and send them pdf’s of that info to see if it did. It was making scrambled eggs.
This was very intuitive, loose, and fluid. As I talked about a few weeks ago, it’s also very much an iterative process. At the start, all we cared about was whether we were creating enough value to keep talking to the sales people:
while ValueCreated:
if SalesPersonLikes and SalesPersonUses:
ValueCreated = True
else:
ValueCreated = False #DON'T EXIT THE LOOP!!
When we were at the beginning of our learnings, the difficulty to provide value was low. We just did a thing and checked to see if it was useful. Then, what could we change to either get more pilot’s in the loop or intuitively increase the value for the ones who were already there?
However, as we kept iterating and solving problems, we created new problems. As an example, one challenge was how do we make the platform as easy as possible for sales people to use? The answer we selected was prewriting an email for them that they could send directly from the platform. Thus, graduation from scrambled eggs to sunny side up.
That, however, created the problem of our value being tied to a single email response rate; if the email failed, we failed, and the sales people would lose faith. So, we started adding other features to encourage other actions, too, such calling the contact and connecting with them on LinkedIn. This is where we started adding in the side dishes.
But now, the platform is not so intuitive; there is so much to do and so little time. Solutions beget problems, and now that simple value creating logic has nuance and tons of variables:
Not a simple true/false anymore. Also, “QualityOfOurInfo” really gets an equation with a ton of variables, itself.
We have the makings of a very good breakfast, but the cappuccino is sitting at someone else’s table and the eggs are on two plates on opposite sides of the room. Oh, and the silverware is in the bathroom.
A note is that the complexity is cumulative, too. Adding one feature isn’t adding one feature and then being done with it; now, it’s a feature that has to be maintained and interact with other evolving features, and potentially delivered to every future user. We’re not trying to make a cappuccino for one user.
All of this is to say that now, other than reducing the man hours required to maintain the quality of our info, one of the biggest things in our immediate control that we need to work on is the UI/UX—the presentation of the meal.
This is interesting to me because even though it seems obvious, I never would’ve guessed that this would be one of the problem variables; I didn’t even realize it would really be a variable.
Solving the Problem
Now that we’ve discussed the problem, we might as well discuss the solution, or proposed solution, I suppose.
All of this stems from understanding the end user whose actually going to be engaging with the product. If the users read Hindi, we need write in Devanāgarī script, not english words in the Roman alphabet.
Unfortunately, we’re not exactly our users, meaning we’re not full cycle SaaS salespeople. However, both Jack and I share many of the characteristics of that sort of role, in the sense that we spend sometime actively prospecting and finding pilots and clients. Which is helpful, but, regardless, the best thing is to watch and speak with the users.
All of that is to say, we’ve learned the following:
Matching Language → One change that we made that seemed to quickly increase usage was switching the status representing which accounts the sales person was working on from “In Progress” to “Working.” This is more common terminology for sales people. So, we’re looking for other ways to print the menu in the write language.
Prioritizing Information → We present quite a lot of information to the user, not only in the sense that they have a lot of accounts, but also in the sense that each account has a lot of information. So, how do we help them immediately determine which information is most relevant? You might fill up on potatoes if you don’t know the eggs are inbound.
Intuitive Workflow → This is in line with the above point. How do we help the user prioritize the flow from one function or feature to the next without getting lost and having to either ask “What should I do next?” or just leave the platform. The fork has to be next to the plate.
Share Success → Now that we have a few big wins among users, we are going to add some sort of leaderboard that will probably communicate two things: Usage per Person and Results per Person. We’re doing that because usage is mapped to results. The guests should be able to see the other satisfied customers.
Again, all of these things may seem relatively obvious. However, if you would have asked me five months ago what our biggest challenges would be, I would not have put UI/UX near the top if it even made it on the list at all.
You don’t know what you don’t know.
A question that might be in the back of your mind is why don’t we hire a UI/UX designer. Well, there’s two simple reasons for that: 1) We are cash constrained; 2) Our UX is probably at a 3/10, and I firmly believe that we can get it to an 8/10 with our own time and effort.
Beyond that, we did know that front end in general was going to be our weakest spot, so we did hire an intern to work on that, and she is doing wonderful. So, while we don’t have plans to hire someone who specializes in UI/UX, we did find someone who has a bit more of an intuitive understanding of it than we do and also enables iteration cycles to be much more rapid.
All of this being said, UI/UX is where some of the most pressing levers that need to be pulled are, RIGHT NOW. But, I’m sure that will change in a month, if we do our jobs well.
I’m making an effort to communicate a bit more clearly with these posts—please do let me know if you have any feedback on the clarity or anything else.
And, if you can’t tell, I take my eggs sunny side up, preferably with cheese.
Live Deeply,