Methods to use in small projects

Design Lounge Usability reviews and research
1

I occasionally coach small teams who work on open source software. They do have limited budget and often no dedicated designer role. I collected some advice I commonly give them:

I wondered what other lightweight (or not so lightweight) methods people in the community made good experiences with!

4 Likes
2

I think this is important advice on how to improve existing software.

I think that observing users of the software is the most important thing. It doesn’t need to be well-prepared user research sessions, just watching people from time to time.

One thing that we did successfully in Forgejo is reworking forms and settings. It allows us to rework some really frustrating and overwhelming parts of the app without much effort:

  • Get rid of dropdowns with few options, they use a lot of space and require more clicks, and users can’t see their options while scanning the form
  • write useful help text
    • write hints for non-obvious settings (e.g. “X permission allows your users to do y and z”)
    • remove repetitive help text from obvious setting (e.g. “X permission allows your users to do X”)
  • group related settings and split monster sections into smaller ones
  • move optional / advanced settings to the end or hide them

Also, this is my addition for creating better things from the start:

  • Decouple UI from implementation: Developers tend to build user workflows the same way their system works. Common scenario: You have an organization, and users, and group them in teams. The data model is organization, teams and users and they need to be created one by one. However, the UI could already create a default team or allow adding people without creating a team first etc (although it means that a single click creates two things in the database)
  • Don’t reinvent the wheel: Sometimes, people think they got innovative design ideas (that are not directly related to the thing they’re building), and then they don’t get it right. Stick to what others do if you cannot design it properly.
1 Like
Your thoughts on dropdowns
3

write useful help text… non-Obvious…remove repetitive from obvious

Yes! And these are helpfully similar on how one should write comments in code (claims of “my code is always self-documenting” aside)

…move optional / advanced settings to the end or hide them

I still like progressive disclosure!

Decouple UI from implementation

Command pattern is very helpful for that:

  1. Decoupling and
  2. Setting up, e.g. a default org when you create a team is very easy with that

Don’t reinvent the wheel

Yes. Inventing something new only if it is really, really needed and based on a coherent concept. It is hard to do right and it usually is unintuitive, cause intuitive = familiar. Fixing it based on feedback later usually leads to more ideosyncratic if-then fixes, but not a better concept.

4

Will try to suggest new things from what was already posted!

  • Ask “what is most important to my user? second important? third? etc.” This can help inform decision making for what to show the most emphasis on a page.
  • More of a visual nitpick but you can convey importance through different sizes of text not bolding everything you think is important.
  • Find a common path users take, make this accessible or easy as possible.
  • Determine if a feature is for power users or a niche case to understand if it should have the same treatment as features that are commonly used.

Get rid of dropdowns with few options, they use a lot of space and require more clicks, and users can’t see their options while scanning the form

I agree with this for the most part but in my current product (I work on a data analysis tool), we actually do have a dropdown that is only a few options (this honestly could be bad UX) but it’s a set-it-and-forget-it option, not the primary input we want users to focus on, and would otherwise take up a lot of space.

1 Like