For PMs at very early stage companies, I’m curious how you get your engineering teams to move quickly and build core product functionality while still having them pay close attention to UI/UX details. I don’t want to come across as too nit-picky but I do want to hold our engineer to a high design bar. I’m also cognizant of the fact that he doesn’t have a ton of bandwidth and has higher priority tasks to work on. Any advice on how to balance shipping something that works well with shipping something that works well and meets the high design bar a lot of companies have these days?
9 Likes
The most impactful means through which I’ve communicated with engineers about UX is via goals and user empathy, and supplementing with comps and examples.
Conveying the moments or beats they’re building and how the user should feel or what your goal is (ie: guiding the user to X) allows them to make critical decisions beyond just the isolated task (“make sure doodad is functional”).
Not everyone has great UX instincts. Comps provide a guidepost for quality to those who are weaker at visualizing. Be sure to highlight the key elements your wanting to accomplish (info hierarchy, lack of friction in interaction, etc).
You mention they’re low on bandwidth. How much do they realistically have to polish UX? Is it something you can time box for them?
8 Likes
We’re a small startup so we only have 1 engineer right now. I could ask him to spend more time polishing the UX or have him get started on another piece of core functionality sooner
7 Likes
I have an early startup, what I’ve done - created a list with general UI/UX patterns that we should follow no matter the feature (like toast messages, notifications, tables, filters, pagination , links, buttons , titles, headers, tabs, etc.) ; described in details repeatable elements , so every time a similar component is about to be build they have to do it the same way as before and they’re aware of this.
6 Likes
One thing to keep in mind is that design and UX polish is super time-consuming. So you really need to ask yourself why it’s necessary. If that’s the highest ROI use of your engineer’s time, then explain to him why and that should help you get aligned.
5 Likes
It might be worth your time as the PM to set some UX standards, similar to what @MariaWilson said. Great UX takes time and skills (which your engineer may not have), but good enough UX is often just following consistent rules. Story time! I was once 1 designer on a large product with 10+ engineers. We consistently had the problem of the final output not looking like wireframes, or the engineers made bad impromptu UX decisions. Since I couldn’t review every screen, I did a few things:
- Made a very small design system for components
- Made a checklist of “rules of thumb for UI decisions” (e.g., always default to left aligned. only 1 main CTA button on the bottom right, always label icons, default to X font in Y color, when to use radio/checkbox/toggle, etc.)
- Shared 10 Usability Heuristics
- Did a lunch and learn where we reviewed the 3 above things
The result? DAY AND NIGHT difference in the output quality. I talked about it a couple months later with a few engineers. They said they were never taught these things, and they had no idea how simple some UX rules were.
4 Likes
I really like @MichaelYoffe’s suggestion, but I also agree with @MarcoSilva in that given you only have a single engineer, I would agree that it’s likely more important that the product works and has the core necessary functionality than it meets a high bar set by teams with far more than only a single engineer. Given that, I’d recommend leaning heavily on an existing design system (like Material) at the moment and just make sure you stay consistent within those well known parameters. It’ll make it easier to implement a branded design system in the future, once you have more room for discretionary engineering projects.
3 Likes
Agreed with all the great thoughts above. Since you only have a single engineer, I’d assume you are pre-PMF and have an endless backlog of core functionality to build. I’d recommend establishing basic UX principles, leveraging an existing component system (we use MaterialUI), shipping fast, getting user feedback, and circling back to areas that you’ve heard customers are struggling with.
Its very tempting to over-polish but you may change the entire design in two months if its an important surface that you’ve gotten a lot of feedback on. we’ve done this many times and I’m always glad we didn’t overpolish the v1.
2 Likes
Unless a really polished design and UX interaction is a core differentiator for your product, it is unlikely that getting things to be perfect is the best use of your single engineer’s time. On the other hand, if what sets your product apart from competitors is truly in the design, or if not hitting a certain level of polish represents existential risk for your product (i.e. not only might customers not use it but would be left with such a bad taste that they won’t even try a future, improved iteration because of their terrible first impression), then it may be worth it to spend the time. But this is rare for most products.
As with every PM role, ruthless prioritization is key. Only you can decide how much to invest in it versus the opportunity cost of not working on the next feature. But more often than not, err on the side of “good enough” and get it into the hands of users quickly.
1 Like
A lot of meaningful answers have already poured in,
- Differentiate between workflows which necessarily need to have refined UX experience
- Which can live with core functionality.
Let engineer make the first iteration for both these sets but for #1, spend 15-30 mins synchronously with the engineer, and make the necessary improvements in place before it goes live. In early startup days of my current org, we used this to have a good balance on speed & quality.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.