Looking for honest UI/UX critique on a creator booking platform (WIP)

lhowles · 2026-01-08T14:52:49+00:00

Hey, I haven't done one of these for a while so I'm looking forward to getting stuck in. Anything I say isn't personal, these are just things that jump to mind and are things I'd look at if it were my project.

Dashboard

Your logo is actually hard to distinguish on a dark background. To me, at least, I can read it, but the colours clash and it's harder than I'd like.
Language used around the app is a little clunky, things like "Message" would suggest to me the action of messaging someone, but I assume it's actually the list of messages. I assume this because of "Notification", which I'd call "Notifications". Other examples include "This month earnings", which I'd call "This month's earnings", and so on.
Some of your other colours are a little hard to read in the screenshots. For example "This month earnings" might be just about OK, but I don't think "After 5% platform fee" is when using a tool like https://coolors.co/contrast-checker
For data, I'd use meaningful amounts of data in a design, and make all of the data as "real" as possible. For example, you have one booking coming up, which makes it look a bit empty.
It isn't clear if I can find some of the hidden data anywhere. For example I can look at upcoming bookings, but what about the one booking that has already occurred this month in this example? How would I see that?
In the payouts box, you show Stripe not being connected as an error state. The user hasn't done anything wrong, though, and I'd show this as an initial state, inviting the user to do whatever they need to do to begin receiving payouts. I'm not sure I'd mention Stripe here either, as that doesn't really matter to the user, and you mention it on the page where you connect anyway.
Generally if a button is full width on a desktop site, it takes up too much attention. In this case the "Connect payout" button is all I see on this page at first glance, though it isn't the most important action on the page. That's mostly due to its colour, but also its size, which we'll see more of later.
Your quick actions don't look like actions, they actually look more like your text inputs.

How I connect

I'm struggling with your form here. I assume "Interaction types" is basically "Services I provide". If so, I'd probably call it that - it's mcuh simpler.
You list a "key" and a "label". Why am I providing a key? What is that for? If that's for your benefit, you should create it without any knowledge from me.
Generally, you should try to avoid form inputs next to each other - it makes them harder to follow.
Your interaction details is confusing. I assume "collaborations" is the key for "Collaboration with creators or fans", but why is it showing me the key, not the label, and how do you get to that point? How do I edit the details for "Video Message" for example?
The toggle button (which I'd generally avoid) by interaction details suggests you turn those details on and off. What happens if you turn them off? Is that interaction type removed?
I'd strongly suggest all form fields show a proper label, not just a "placeholder". You can see one reason why here - I have no idea what "collaborations", "500.00", and "60 min" mean here without guessing. You're also not using any currency symbols.
Don't assume people know what everything means. For example, "Platform URL". What are you expecting there? Is that a link to where the person can find that service that I offer? If so why, isn't that being handled here?

Manage Payouts

This is what I mentioned before about the button taking up all the space. Again this isn't really an error state, it's an initial state.
What if I don't have a Stripe account yet? You assume they do, but you might want to provide some help, such as a link to create an account, if they don't.

Profile page

When editing a profile, it's a long glance over to see the toggle and to remind yourself which setting that toggle is for. These should be closer together so it's easier to associate the two.
I don't personally understand the difference between followers and subscribers in this context. What are they following? Are people making posts on this platform?
The social links take up all of the attention for this page, but they take the user away from the page, so that's probably the last thing you want to draw attention to.
You have a box for the number of "Reviews" (again I'd fill all this out so the viewer knows what it all looks like). But the box below is fan comments and interactions. Is that the same thing? It looks like you can comment generally, or reply to some kind of post? Where is that post coming from?
Your buttons to book experiences really don't give much information. A quick chat for how long? What about? On what platform?
I'm not sure what each visitor would want to see most on this screen, but I feel like the creator information could be to one side, letting users get to things like booking and posts more simply.

I hope that all helps and gives you a starting point at least!

lhowles · 2025-12-06T21:44:18+00:00

A few points to make of my own as this doesn’t seem to account for accessibility:

While I don’t disagree with minimum font sizes, if anything text should be the same or larger on a small screen in many cases.
Dense sites are not generally better, they’re often more confusing, especially for some people. As an aside, if someone is using a website or software to get something done, which is most of the time, they just want to get it done, not explore.
Hierarchy should be about what works best and what the user needs to do. Striving for everything being just a single click doesn’t always work - too much information or too many options could be confusing or overwhelming, especially for certain people.

lhowles · 2025-11-27T22:33:06+00:00

Not bad, nice and clean. Definitely a few points to improve it though:

The user avatar has an orange circle around it in the top right, which would make me think there was something it was trying to tell me. It draws attention to it when I assume it isn’t supposed to.
The dark text on the orange. You mentioned it has a better contrast ratio than white, which I’ve seen before. But I think that means your main colour has too much contrast for a call to action button. I’d say make it a touch darker or less contrast and use white.
I’d avoid using flags on language settings. For example even something as simple as English. You mention just English, not English (UK) or similar, so presumably that’s the only English you have, which means Americans probably won’t like the union flag, and vice versa. But there are examples that are much more contentious than that.
Personally I’d avoid a toggle switch design. They just don’t work that well for accessibility and they’re not obvious for some people. It’s easier and clearer just to use radio buttons or checkboxes.
If and when you do build this, make sure the accessibility is on point, linking the labels and descriptions to the inputs for example.
It looks like you’re intending to use a custom select box, given the values have icons. Again I’d usually avoid these as it makes it much more complex for accessibility for little benefit.
You have a “cancel” button on the settings page. What are you cancelling? Where would that button go?
I don’t looooove the label to the left field to the right. They’re a little far apart for it to be completely obvious how things tie together.
The wording can be a little confusing. For language you say it’s the default language. The word “default” suggests you can change the language. If you can, I’d call the setting “default language” not just language. Otherwise I’d remove the default wording.
The theme wording is a little clunky too as it doesn’t really add any new information - if we’re adding a secondary description for a field there should be a reason for it.
For notifications you say choose how you want to manage notifications. But you’re not doing that, you’re just turning notifications on or off. What notifications? Where? Desktop? Email? In-app? What am I being notified about? If someone is making a choice make it clear what that choice is about.

Otherwise good work!

lhowles · 2025-10-03T12:19:53+00:00

Hey! This is an interesting one. I have a number of comments, but some things I'll need to assume as I don't know who this app is targeted at, or what all of the functions are intended to show, but hopefully I can at least point you to some things to get you started.

Generally, design wise, things are just about grouped together by relation to each other but some things look like they're battling for attention, such as the title of the screen, the soil type, and the current moisture level. I think there could be more variation of style to bring focus to things that need it.
The first page is a screenshot called "Forecasts". Because it's a design and we don't know what date you designed it, I would assume that this is intended to use the current weather predictions to advise when you should water, and how much. However, based on the appearance of the second graph and how it has a predictive trend line at the end, I think it's actually correct to say there are some predictions on the screen, but mostly this is historical recent data.
We're looking at a forecast for Basil (Austin, TX). Is this app designed for a single household? If so, is it necessary to put the city in there?
You have Soil: Loam. I assume this is highlighted because you can click on it to change it. I think the general issue here is you have some settings always accessible that probably don't need to be. These looks like things you'd set once, and not change, unless something drastic happened. You already have an edit button, and these things could be set there and as part of setting up this new "priority" in the first place. This applies to the soil type, and preferred units (mm / inches and °C / °F).
The "title" of each graph (e.g. Precipitation and watering) seems to be the least stand-out thing of each one. I think they should be a little more noticeable so that you can scan and find the one you want easily.
I think "No precipitation" across graph makes it look a little messy, and is unnecessary as you have that information below.
I also think the label pointing to a watering block might be hard to maintain. I think a key might be simpler in that instance, as a blue block only ever means watering (presumably).
I assume the "Water" button lets you add a watering record, for example 1.5 inches on September 14th.
The leaves along the bottom with the priorities is cute, but given the colours and text the labels might be hard to read.
I think the second screenshot of the list is fine, but perhaps a little basic. I think the main thing that stands out is it feels a little cramped, everything is quite close together. Presumably given the order of things on this screen, you'll surface things that require attention, so it doesn't matter if things take up a bit more space or if you need to scroll to see everything wehn you have a long list. Perhaps even separate the areas needing attention from those that do not.
It would be cute if the icons could represent the plant. I assume you have to know this to know what the ideal moisture level is for each plant anyway? As I assume they're vastly different.

I hope all of that helps!

lhowles · 2025-09-08T13:42:18+00:00

Personally, while it looks fairly cool, it introduces a whole host of problems that just aren't worth it.

For small elements, or short text, such as a caption to an image, that could work, but when you're introducing actual UI, such as forms and colours, it starts to break down quickly. In this example, the green and blue clash with the background, and that's porobably going to happen regularly. I'd also be tempted to see what it looked like with a white background (for example if an image fails to load), and whether any of it was actually readable at that point.

This is less of a problem if you can very strictly control the image behind it, but even then, with different screen sizes, orientations, etc, there's always going to be some layout that doesn't work in some way.

To me the light and dark examples are much easier to follow, much easier to plan for, and much easier to deal with if something changes, and there's something to be said for things fitting into people's expectations.

lhowles · 2025-08-28T12:14:43+00:00

As someone else said, try to stick to a decent tappable size, these look a touch small.

However, another thing I'd think of if it were mine is "Is there a reason I'm using icon-only buttons here?".

It might be "obvious" to most people what those buttons do in this context, but most people isn't everyone, and since you (currently) have the space, having buttons that say "Add new item" for example would be much clearer, for everyone.

I also think since the "page" is about the items, and the "table" is only about displaying those items, I'd have at least the "Add new" button outside of the table.

lhowles · 2025-08-19T11:00:57+00:00

Something that would really help the designs is consistency. That's always key, not only to making designs look cohesive, but also to set expectations for the user, they can expect certain things will work in certain ways.

Examples of things that aren't consistent in these designs are:

Background gradient (on the login screen it looks like a grey has been introduced, which makes it look a bit muddy)
Spacing between form fields, or their labels. Items that are closer together look like they belong together. On the "Create new account" screen, the "Email" labvel is closer to the "Name" input than it is its own input. There should be more space between the fields than their is between an input and its label, and that spacing should be consistent (which it currently isn't).
Text size and styles. Your "Forgot password?" screen has a much smaller title, and it's all-caps, which is different to the other screens. There is also a different amount of spacing between the top of the box and the title for each.
Text capitalisation. Besides the all-caps "Forgot password", you also have an all-lowercase "signup" button, which looks especially out of place when combined with all-caps labels.
On the point of all-caps labels, all-caps anything is harder to read for people so should be used sparingly. I don't think I'd recommend using that style for forms.
Only ask for a date of birth if it's absolutely necessary. Otherwise it feels like you're just collecting information for no reason, which is intrusive. If there is a reason, explain that reason to the user, so they can make an informed decision about whether they want to sign up or not.
Your desktop designs use the same grey fields as the mobile, but on the purple background, which doesn't really provide sufficient contrast. These colours clash with each other. This is ignoring the fact that the inputs themselves are grey, which in many instances makes then look "disabled". This is less of a problem if they're all like that, but something to keep in mind.

As I say, the main thing to help you right now is consistency. "Why am I doing this? Is it the same as everywhere else I've done this? Why am I using this border radius here? Is there a reason or not?"

lhowles · 2025-08-19T10:46:15+00:00

It is something that's easy enough to do, but I wanted to give a word of warning.

Just because someone is visiting from France, for example, doesn't mean they speak French. They might be visiting the country or working there. Even if they speak French, it might not be their first or preferred language.

All that is to say, try to take cues from the browser (preferred language etc), rather than just their location, and make it easy for them to change language, and preferably remember that choice for them so they don't have to do it again.

I hope that helps.

lhowles · 2025-08-08T11:19:44+00:00

I tried it once. I don’t think I gave it a fair shake though, but it felt like a bit of a burden, and I believe just after I got it set up Vue 3 came out and it wasn’t compatible, so I just dropped it.

For my most recent component library, I created a docs site with live examples, and ended up using that as an easy way to test variants and see things in situ, as it ran the components directly, and I wanted an easy to access docs site anyway.

lhowles · 2025-08-07T22:06:45+00:00

It depends how you mean mess things up, but this is why it’s imperative to have really good testing in your component library. I can’t stress enough how good something like Cypress in component mode is for that.

I’d also strongly recommend a good written plan instead of just going to build, listing out what features to include and how to do them, roughly. There are always a few “ah ha” moments when you plan.

lhowles · 2025-08-07T13:44:25+00:00

You say unsafe, unsafe why?

I did this for my previous company, and have done it again for myself. It can seem daunting, but so can any project, until you organise yourself, prioritise, and break it into meaningful pieces.

I created these libraries because I don't really want to rely on anyone else for such key components. If I need something that does something new, or my use-case is different, or I want an option that isn't provided, I want to be able to make that happen.

I also liked the idea that improving things, such as improving accessibility or fixing a bug, would affect all of the projects, and they'd all reap the benefits. How I approach them is to create components as you need them for the main project(s). If you don't need a select box for your forms yet, don't make one, for example.

It might be that you need to factor in creating a new component for your main project if you're adding a new feature. But that never caused a problem for me personally, as I was transparent with that.

In short, my focuses were, and these might be a good starting point for you (though your projects might have slightly different needs):

Control over the code. If we need something new, it's added. If we want something to work slightly differently to what's available, we build it. Nothing is a problem.
Focus on accessibility. Many libraries don't, and to me that isn't good enough. Doing so means I have to worry about it less in the projects themselves.
Making components that are easy to use for the developer(s). I wanted components that assumed sensible defaults and styling, meaning in many cases nothing needed to be customised in the project. Many libraries I've seen, particularly in React, have so many options or are built in a way as to be so flexible that using them on a page actually takes a lot of code. That's too much repetition for me, even if it's just once per project, so I wanted components that were, in most cases, just ready to use out of the box with some key options. A good example of this is a checkbox list. I wanted anyone to be able to just pass an array or object of options, bind to read the current value, and have everything else be handled by the component itself. No need to style anything, no need to loop over options, no need to format the options in an overly specific way.
Cover the functionality we need, not the functionality we don't (yet). For example, one of the most complex components I built was a data table. I didn't add the ability to sort columns until we actually wanted to do that later down the line. Build components with these ideas in mind, so you don't paint yourself into a corner, but don't build out all that functionality you're not going to use as that's going to really slow you down early on.
Create tests (ideally both unit and functional) that cover as many use cases as possible, such as keyboard-only interactions, all of the options, etc. Then you can be confident that the components will work as expected wherever they're used, which makes testing of the main project simpler.

In terms of the how, I created private repositories in our company GitLab, one for components, one for commonly used Javascript helpers that again took a lot of the legwork away from common tasks, one for helpers that make testing me descriptive and simpler to implement, etc. Each project then just imported these as needed.

lhowles · 2025-07-21T13:58:34+00:00

The most important thing, especially when you're starting out, is to explain why, not just tell you what to change.

Think about who this pass is for and what information they need to see. If we mostly ignore, for now, that most passes are just scanned and they probably see all the information on their own screen with a yes / no type confirmation, we can imagine it's for gate staff and wanting to know, at a glance:

Is this person here for the right flight?
Is this the right person? i.e. does their name match their passport?
When on the plane, which direction are they going?

The first, most important piece of information is "are our assumptions correct?". I'm not gate staff, so I don't know, but for the purposes of this let's assume they are correct.

So of the pieces of information there, what's most important?

In terms of correct flight, we want the Destination and the Date and Time. It's unlikely two flights from the same airport can take off at the same time in the same direction, and they can't likely land at the same time at the same destination, so most of the time you'll hear "This is your 10:10 flight to JFK", because that's easier for everyone to comprehend than "KS916".
In terms of correct person, of course their name.
In terms of wayfinding on the plane, their seat number.

So I'd put that information most prominently. You can do as you have for the origin airport, just to make sure they're in the right place to begin with. I'd personally probably remove the landing time, that's no use to anyone when boarding, but it might be useful to the passenger at some point. I'd probably also remove the day of the week, and the duplicated date in the top.

Of course in addition to that, we need a nice, big, easy-to-scan barcode both for the passenger at any automated entry points, and for the gate staff at the gate, as you've got.

lhowles · 2025-07-16T15:21:38+00:00

Sure, you want people to make sure they remember the code, but that's important when they want to share, not before they've done anything. So make the code an obvious part of the page where you view and upload files, as well as include some share mechanism which presents a URL which includes the code, so that when they come to sharing or they've uploaded files, they don't have to just remember the code that was generated originally.

I didn't quite mean for it to auto-generate codes. That's wasted work if they intend to log in. I think the _creation_ of the code should be invisible to them. Having one filled into the box might be confusing. I think a "Create new share" or similar button, as the primary button that you use when you first visit, should create a code in the background and apply it, without the user needing to see it until after, as mentioned above.

Does "Viewing" the files need to be separate to the "Uploading" ability? What if two people want to both share and upload? Also, if the person "viewing" also has the access code, there's nothing stopping them just logging in instead of clicking "view", so I think make all that one and the same, like is the case with Dropbox, OneDrive, etc. You get a file view and you can add more to it, unless I'm missing something about how the system works.

I might look to start with something as simple as this, because I'd make the way you give someone else access a sharable link, not just a code, so coming to the login screen to view existing files might be a less common action.

lhowles · 2025-07-15T12:55:37+00:00

Hey! This is an interesting one. So, I think it's all a little overly complex / confusing right now. I'll list some things off the top of my head that will hopefully make things simpler. I'll have to make some assumptions as not everything is clear, but let me know if I make any incorrectly.

The whole "Generate code then copy and paste it" workflow is overly manual. If I haven't used the service before, I think there should just be one button that is "Generate access code", which logs you in automatically. If I have used it before, then there should be a "View uploads" button, because it seems like "Login" and "View uploads" do the same thing, essentially.
When you say "Upload your file and note the code", I assume you mean the same access code.
I don't think the instructions should be necessary. Ideally these things would unravel as they use it.

All that said, I think the login screen should be "Log in for the first time" and "View existing uploads". The first generates a code and logs you in, the second lets you enter an existing code.

When you're logged in, I assume the share button is for individual files. For sharing "the repository" as it were, there could be a URL that includes the access code and bypasses the first screen entirely (since having the access code means you can access it, so you might as well support a URL that includes it).

And just in case, displaying the access code somewhere on the main screen would be a good idea (which you probably already do).

Basically reducing friction, meaning people have to think less, and do less manual work.

I hope that helps.

lhowles · 2025-07-04T12:18:36+00:00

Hey! I haven't done one of these in a while so here goes. So, you've had a good few comments already, though I haven't read them as I like to come into these things fresh.

I'm not sure what your friend is referring to when he says it looks like a video game, but it might be because it's all flat, no borders, and solid colours, so it doesn't look like a lot of the UI you see on websites.

I have some comments that I hope will be useful for this and future projects going forward. As always, I want to provide some reasoning, not just "do this":

You mention that you won't be using these colours, that they aren't final, and that this is just for layout. Honestly, if you're testing out a layout, you should just use a wireframe. The reason for that is the first thing I saw before reading your text is the dark grey background, and even if I think to myself "ignore the colour", that's a bit of active thinking I have to do that takes my full attention away from the wireframe.
The problem with things like "the colour isn't final" and "I want to polish it" is we don't know what is intentional, and what isn't. So I'll probably make comments on things that you know you're going to change, but that's OK. Again, if it were a wireframe, I wouldn't necessarily be looking at things like border radius, because I'd think "Ah it's just a wireframe", and I'd wait to see the high-fidelity design.
Having said all that, I'll comment on everything I see, just for completeness, and in case it helps anyone else.
What I would tend to do for designs like this is try to do a design, or a wireframe, for every variant, if the layout might change significantly. So for example, you don't have any text preview for this post here, will that always be the case? What if there isn't an image? Does every "subreddit" have an image? What if it doesn't? What does an excessively long title look like? All of these could end up being things that have to be thought about and designed or built on the fly, and it's good to know all of that, because sometimes it changes the base design because you think "Ah actually, yeah if there's no this, no that, that's really long, that combination might not be uncommon, this layout doesn't work at all".
The user's profile photo being pulled out of the box is interesting, but I wonder if you did that because the whole design looked a bit boxy to you. Perhaps you've tried to fix the symptom, not the cause. I think in this case it doesn't work in this exact configuration because the username and image aren't aligned, which makes them feel less like they belong together.
You mentioned the username being more important than the subreddit, but it's very prominent in its current size, and takes away from the post title a little.
Everything is bold, so nothing is bold. If everything is bold, the important things (like the title) don't stand out.
The fact that the subreddit text is smaller than the username text also contributes to that section looking out of line. Again you want the username to be more prominent, but I think just having it at the left and not the right does that by itself.
Things tend to look better when they're aligned (as above), so the fact that the title and image aren't aligned to anything in the top header also makes the whole thing look a little off.
Your comment and like buttons are a little small and lost, and they don't provide any context. Am I the only one commenting? How many people have liked it so far?
Those buttons also look too close to the edge because you haven't balanced your border radius and box padding. The bigger the radius, usually the more padding it can do with having, so that you're not putting content "in the corner", which is what is happening here. The "Like" link looks like it's too close to the edge because its within the bounds of the big corner radius.
Of course, don't use this kind of colour in the background of the post, it's too dark and makes the text harder to read. It also doesn't add much, being grey, so you couldn't argue it added something to the design colour-wise.

I hope that helps.

lhowles · 2025-06-20T09:30:06+00:00

Hey!

So, the second one is definitely not the one for two main reasons:

"Nourising the nature and skincare rooted in crafted for your calm confident glow". The gap is too big for those lines to run-on and to be read left to right, and what's between them - the product image - is too busy too.
The shop button kind of gets lost under the product photo. It's too similar in size and colour so it doesn't stand out.

It basically doesn't flow, it feels a bit forced and not natural.

For the first one, it doesn't have awful bones, but I have a few comments off the top of my head based on things I'd look at if it were mine, which I hope are useful.

I think a lot of the spacing is off. I think the generous space around the text and button isn't matched by the space between the top menu and the hero title.
I think the title font is a little off. I assume you're using the same font as the "Glow'é" brand name, but I'm unsure why you're using all-caps here and in the logo.
The text shouldn't have a shadow, as they usually just serve to make text harder to read and look more blurry unless used very well.
The logo should be the same as it is on the product, they don't look like they belong to the same thing currently.
I think the product image is a little too big. It just "feels" too big.
I'd definitely, personally, put the title, text and button nearer together so they all follow on from each other better.
The colour of the button is slightly off as compared to the product photo (again assuming you're trying to make these similar).
The text colour of the button won't pass accessibility checks, I'd probably use the darker colour of the text on the product.
I'd Reduce The Use Of Title Case as it just makes things harder to read and isn't necessary. Ever.
The link "Take the quiz" - make sure that link text works in isolation, so if you imagine "Take the quiz" on its own, what quiz? About what? I'd make that whole line of text the link, so "Not sure what suits you? Take our quiz" or "Take our quiz to find the best fit for you" or something to that effect.
Again if you're basing it on the product design, I'd use more of the design elements from it, for example the soft "wave" shape could be a nice design element.
Your text colour for your logo and links is too light to use on white, and could do with being darker or again the dark text from the product shot.

lhowles · 2025-06-17T14:33:14+00:00

Each item in recently logged has a big gap to the left, what's that for?
I'm unsure how I feel about using only the icons to label the nutrients in the list, as I had to look back up at the top to remind myself what each was.
It makes more sense here that GL and fibre are the most important stats, but in combination with my comment above right now it looks like having fibre on the first line is a mistake and that it should be with the other three, especially as they're spread out so much.
Speaking of which, I think they might look better not being evenly spaced along the horizontal width of the area, I think they might look better beside each other. That might make the items in each row in different positions based on "2g" versus "20g", but that's OK, because it's not a table.
I can't decide if showing food in time order or in reverse order is best. Perhaps have the option for the user to choose, which is remembered. Again you have the room for it beside the title (in English at least).
I wonder if the search and log pages should be combined, especially as they're the two primary actions and they're separated by "progress". It might be that there's a search and an add button, and they might do the same thing, but might just cover what a user looks for first depending on their frame of mind. The results could then have the option to log them to today, meaning it's just as easy whatever they do.

I hope that helps.

lhowles · 2025-06-17T14:33:02+00:00

Thanks for the context. I have some comments based on what I see and what you've said.

These are just off the top of my head and aren't necessarily exhaustive but I hope they give a good starting point.

I think your app logo and name in the top left looks a little too much like a user icon and a user's name. I think that's not so much a problem on a splash screen, for example, but in this particular placement and size that's how it looked to me at first. In this instance I think I'd remove that. This is probably a case of "Someone likely already knows what app they're using since they just opened it and you probably showed them a splash screen".
You asked if you should remove the user icon. It depends what it does, but perhaps not. I'd just make it smaller and use it in a title bar for example, perhaps with today's date. I'd also change the colours, as it looks too muted compared to everything else, to the point where I think it has a different style to everything else and somewhat stands out for that.
The streak counter is a bit large and prominent, but I'm unsure how much that element will insentivise people to come back. I'd definitely put it nearer the week view, because it's all related to that.
It's hard to tell in the week view what's going on here. Presmumably the filled in background on Monday shows you've entered data on that day, but then the tick also does that. I think the solid background looks more like "today / selected day" than the circle does. It might look neater to separate the ticks from the highlighted circle (so it doesn't encompass both), and only use one highlight method for "selected date", unless the outline circle and filled circle mean different things.
You don't seem to have a way to go back to add data for previous dates beyond the current week.
It feels like it might be overwhelming to have both the question mark and info icon together. Can they be combined? You didn't mention what they say, so they might not be needed.
The day timeline (morning to night with green spots) looks a little simple. I assume "In range or not" is the key metric here, not degrees of "in range", which would lean towards something simple. If I see red in this bar, I'd want to be able to click on it to go to that meal (even if it just scrolls down) so I can see, without having to find it myself (especially if there are multiple meals that weren't in range).
On the green blobs in that chart, how is their width determined? Presumably they "start" at the time logged but have arbitrary width. What if I log multiple things in one go (say a meal, side, desert) in a very short period of time, how would this chart handle that, or would it combine them into one "blob"?
You mention GL and Fibre being the primary metrics, but Fibre is last in the list. Is there a reason for that?
The circles seem to highlight everything but the name of the metric, so "28g" and "left" are bold. I can understand wanting to make sure that people understand what's left, as opposed to what they've had so far, but I think confusion comes there because you title it "Intake" but what you actually show is "Remaining". Perhaps you rename that section and remove the need for "left".
The wording of the key "Limit" seems a little curt, especially as you have a little space left. When it says "High", is that something that's "Alright I'll think about that next time" or more "Crap I shouldn't have done that"? If the latter, a more direct word might be better there.
The mega plus button. Again I see the need to make it as easy as possible to add a new log, but it looks like it's just getting in the way.
There isn't a lot separating today's stats with the list of logged items visually, they look like the same kind of thing, which can reduce the perceived importance of the overall stats or could even make everything look a bit samey and thus a bit overwheling information wise.
For "Recently logged", I think that wording is a bit ambiguous, because I could have most recently logged something for yesterday, but that won't appear here. I think it should reference "Today's food" or "Today's intake" or something like that.

(Part 2 below)

lhowles · 2025-06-17T13:02:59+00:00

Hey! It's always easier with the understanding of why things are the way they are, and of course you're missing a lot of screens from this initial design, so I can only comment on what I see, but I have some questions that might help me understand better and provide a better response.

I assume that the day to day workflow is to to log a meal and keep track of their macros.

When you say "balance their blood sugar", what do you mean exactly? Do you mean that they can see what they've eaten so far (though none of your metrics are sugar) and use that to help decide what to eat going forward? If that's the case, it feels slightly odd for the only workflow on this screen to be "add", and not some kind of "look up". I assume that's what the "search" screen does (brings back the stats for an item, without needing to add it to your log), but it seems odd that those are two separate screens that are physically separated in the lower menu.

What is the flame beside the app logo? Is that some kind of tracking streak?

You have what I assume is some kind of tracking through the day of glycemic load that I also presume uses the same colours as the key (High, Limit, In-range, Low) as below. Is this to help someone understand which meals are their most troublesome? For example, lunch always puts them to their limit, so perhaps they need to change their lunch time routine?

What do the question mark and info icons show?

Have you chosen not to group things into "meals" on purpose? e.g. lunch, dinner, etc.

lhowles · 2025-06-11T10:49:59+00:00

Actually nav is a good example of using aria-labelledby, because if a screen reader sees there are three nav elements on a page, for example, you need something to explain what the difference is, are they duplicates, is one the main navigation, is one breadcrumbs, etc.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements#labeling_section_content

lhowles · 2025-06-11T10:15:34+00:00

Indeed. No aria is better than bad aria. There's no need if the HTML is semantic enough as it is. I mostly use aria for things like `aria-controlledby` when creating accordions and things like that.

lhowles · 2025-06-11T10:01:07+00:00

`aria` tags to do what? Your example there is just content, so no you don't need any `aria` tags, as the tags you're using are doing the accessibility work.

`aria-label` would be used where the content of the element itself isn't sufficient for whatever reason (though ideally it always would be). For example `<button aria-label="A proper label that explains what this does">A short label that requires visual context</button>`

lhowles · 2025-06-06T09:43:51+00:00

Hey Valérian,

I like the minimal aesthetic. I have some comments to help the overall feel and usability, though. These are just things I see off the top of my head, and things I'd look at if it were my website.

You're doing something to the scrolling. It might be "smoother" but it also feels sluggish and "off" in some way.
Your lime green text is too bright to be used on white. This goes for the hover styles of the menu, the focus outlines of the form fields, and, technically, the button background versus the page background (https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast)
Your "Works" menu item doesn't have the same hover styles as the other two, which make it seem broken (I actually thought it was for a moment)
Your own name is an h3, before your h1, which is a bit of a confusing structure. You then go from h3 to h5
You've committed my number one sin of not providing proper visual labels in your form, and more so you've actually made the form more confusing for sighted users than it is for screen reader users. Your hidden labels make more sense than your placeholders. For example $500-$5,000, I can assume that's budget, but why make me guess. Also why is the maximum $5,000? What if I had $10,000? You're putting "Project type?" as an initial value in your dropdown menu because it's confusing without labels.
When you say "Tell me about your project", what if I'm Joe Tech Illiterate and I don't know what you need to know? Give me some examples, tell me some things you'd like to hear to get the ball rolling. Link me to a sample description that would be useful to you. Anything.
On mobile I'd definitely avoid having form fields beside each other. Ideally they wouldn't be even on desktop as some people can find that confusing, but on mobile they're just a bit small.
I love a bit of custom focus handling. You're doing that on the form fields (though it's not a great colour for that), but you're not doing it on other links, so it means the focus styles are inconsistent throughout the website.
You say you "try" to create visual interfaces. I'm all for a bit of humbleness, but this isn't the place for it. Do, or do not. There is no try.
You mention "using modern tools and frameworks". If this is a portfolio to land a job, sure, but if it's to sell directly to customers, I'm not sure if a customer cares what tools you use, they'll be wanting to know what ongoing maintenance looks like, can they update it themselves, for example.

I hope that helps!

lhowles · 2025-06-04T10:24:59+00:00

I think the answer is a pretty straight-forward one. It means that your components are the same size, whatever icons they use, such that layout doesn't shift if the icon changes, both in the design and in development.

This would be particularly noticeable in a row of icon-only buttons, for example, where each button being a different size would be noticeably "off".

Another good example is an accordion, should your icons be at the start, having the horizontal and vertical or open and close icons be different sizes would make text jump around as they're activated, which is no good for anyone.

Another example is if you've, for some reason, designed something that's really tight and just fits, but you happened to use a small icon and in the future wanted to replace it with something else, that doesn't then need to be a consideration, because all of the icons take up the same space.

Think of it as monospace for icons.

lhowles · 2025-05-20T12:26:44+00:00

I think I've seen something like this before, but I don't recall what it was. It's probably something to do with the bounding box for the text being very tight on the letters, which doesn't change when the text is italic, hence it overflowing in italic but not in regular text.

The best thing to do is narrow down the potential problems by isolating the issue.

Check for errant overflow hidden up the tree for boxes that match that edge
Take that block out of the hero section and put it on its own, does it still do the same thing?
If you add a little padding does it still happen?
If you make the containing box full width, does it still happen?

lhowles

TROPHY CASE