<abstract>A friend recently asked me to review their UI/UX design in a private app they'd written. I responded with the following in an e-mail, reproduced and lightly edited/extended here for limited posterity.</abstract> The following factors strongly influence and/or limit the kind of review I'll be able to provide. <ul> You dropped the app into my lap with no introduction whatsoever. I don't even know what the app is supposed to do. I don't know what experience you have in UI/UX. I'm assuming not a tremendous amount, but that you have good instincts that can be honed. I will, as usual, start from, 'in the beginning, there was nothing,' and proceed from there. </ul> Here we go. <h>Terms</h> <img attachment="ui_ux_design.webp" align="right" caption="UI UX Design"><ul> UI is "user interface", encompassing the look and feel of components in a UI UX is "user experience", encompassing the underlying concepts, like how to handle lists, large lists, how to select items in a UI, how many items are represented with which controls, etc. There are even deeper concepts, like how to group controls, how to handle navigation, etc., etc., etc. </ul> <h>My qualifications (a short history)</h> A bit of history about me first. My experience in this whole area is as follows. When I was coming up in the early-to-mid 1990s, there really were no UI/UX designers for most software projects. Everyone worked on their instincts. Projects were managed completely differently, with no bug trackers, so you can imagine that no-one really thought much about providing UI/UX guidance in any structured way. It was left up to the programmers to decide how things looked, and programmers were the ones that had to start figuring out that UI and UX weren't the same thing. Programmers started applying architectural rigor to UIs. You'd come up with common controls. You'd use a common palette. I remember hand-drawing hundreds of icons. I remember writing code to make the Windows 95 3D-look for our custom buttons because there was no standard support for icon buttons. I built my own web site long ago, with a highly standardized framework and, hence, user interface driving it. I am a huge fan of CSS and, thus, consistency. I've built a lot of software where we had to "wing it" and come up with a coherent UI/UX on our own because the client wasn't willing to pay for an external designer. I have often built UIs and UXs that I think are good enough, or even pretty good. I know what the rules are, in general. <ul> Know what your use cases are. Know who your actors are (user capabilities). Be consistent. Lean on the platform wherever possible. Lean on metaphors that are well-known to the target culture. </ul> For general-purpose software where you can't control for the audience: <ul> Be aware that other cultures have different expectations. Be aware that people have wildly different abilities. </ul> So, that's the background on me and why I simultaneously believe that UI/UX designers are essential <i>and also</i> that I'm also pretty good at building coherent UIs. I'm at least pretty good/qualified at figuring out whether other UIs are coherent and coming up with what I think are reasonable suggestions for making them so. <h>Some background on UI/UX</h> Since I wasn't told what the app does, I'm left to "discover" it on my own. This is one of the important dimensions of UX design: how "discoverable" are the concepts and features of a UI? How much external support and written guidance do you need to provide in order for a target user to be able to use the app as intended? How <i>much</i> of the app is discoverable? Do the discoverable features form a coherent layer of functionality that serves a target group, i.e., "use cases"? Another interesting question is: is the goal of the app to be easily discoverable? For example, some games encourage reading the manual and figuring things out with more effort. For apps that straddle the world between productivity app and game, it's worth thinking about and noting what the desired effect is. Perhaps a bit of frustration is what you're going for. Note that the entire app doesn't have to have the same level of discoverability. Advanced use cases can be addressed with less discoverable UX. Those are what we would call "learnable" UI/UX. You aren't likely to discover it on your own but, once shown, you can "learn" it relatively easily. A lot of UI and UX machinery that we consider to be intuitive and coherent is actually based on patterns established in our operating systems, tools, devices, and apps over decades. These have often been refined over decades of hard-won knowledge about people with widely differing levels of access. The web standards are very much like this. You ignore these standard into which so many organizations have invested so much to your detriment. It's often best to lean on these commonly understood visual languages unless there's a strong reason not to. <h>Some stuff about your app</h> These are mostly just observations and questions I made about the app in question. I include them here to illustrate the style of the review. <h level="3">General</h> <ul> I tested the web version. The iOS version didn't want to start; I didn't investigate whether that's a configuration problem on my end. The "About" page crashes for me, so I wasn't able to learn what you think the app's purpose is. </ul> <h level="3">Use cases</h> <ul> I'm not confident that I discovered the use case for the app. I can see these:<ul> User wants to add an entry to a log. User wants to view existing log entries. User wants to see information about the application. </ul> </ul> <h level="3">UX</h> <ul> You have two different types of input controls (the first three are one type; the fourth and fifth are another type) and it isn't clear why. On my laptop, the fourth and fifth inputs as well as the submit button do not appear on-screen (there's a scroll bar). Given the scrolling, it draws attention to how much space the nearly empty header takes. What is its purpose? The bottom has three buttons that also take up about 2cm of vertical screen space. Are we sure that's necessary? The validation is enforced, but not clear. </ul> <h level="3">UI</h> <ul> It's not clear which fields are required. The line-breaks in the character-count widgets are odd. It feels like these could fit somewhere else that doesn't use as much space. The color choices are unique, which is fine. The fore- and background colors do not have enough contrast to one another, which is not. The "Record" icon is a "save" diskette, which is a bit confusing. The "Log" icon makes sense for users of Git: is that your audience? Do you even need icons if you have text? What if you made the button look more like buttons? It is not clear that the "submit" button is disabled when you haven't entered everything. </ul> <h level="3">Recommendations</h> <ul> Make sure that the submit button is always on-screen. Consider combining the header/footer to save space. This about whether you want to have two different ways of collecting text/showing character count. There are more responsive ways to do this with CSS grid layouts (which are perfect for apps like this). </ul>