mmlkrx / mini-invoice Goto Github PK

Collection of all types of inspiration to help with designing.

The app should be delightful and fun to use. I'm not shooting for the stars but little things can make a big difference. One great example is the dinosaur chrome game when you don't have a working internet connection. It's a fun little Easter egg.

Fun ideas:

• Mini game of little dollar signs ever so slowly floating up on the side of the screen (almost like a background) and when you click on one it - poof - disappears and you get a point on the scoreboard (or a dollar is inserted into the invoice total) and as you click them, they start to float up faster and faster until it gets really difficult to hit them.

Design Principles:

• The software should cause as little negative emotions as possible to people and be as pleasant to use as possible (this is the single most important principle, every other principle follows from this one)
• It should be simple to use
  CLI approach for GUI; survey people and find out their most important need, then only show them UI elements that help them take care of that need. Once they become more familiar with the app or need more features, make it simple for them to enable UI elements that support more advanced features. The user shouldn't get Photoshop if they only want to convert a picture to black and white. They should use it like most programmers use the Git CLI; learn a handful of commands and use those for months or years and be happy, but be equally happy if their needs grow and they need more functionality. Hide complexity from them, allow them to discover features at their own pace of learning.
• It should be very easy to switch to a different invoicing software if the users needs aren't met
  The user should have zero anxiety about vendor lock-in. Their invoicing and client data is most likely important to them. Allow them to take that data to other popular invoicing software. Depending on how big of a fear this is for the user, make it apparent how to do that, maybe even work with other apps together and offer switching with the press of a button from within your software.
• It should run very reliably
  Money usually has a strong grip on people, I need to survey this to make sure but I think it's reasonable to assume that the software should work as reliably as possible to make sure people get paid. This means it should be simple. Considering to use Clojure since one of it's design principles is to make building more simple software idiomatic. Rich Hickey is onto something.
• It should be easy for other developers to help improve the software
  The user experience is more important than the developer experience, but if possible, making it as easy as possible for people to help would be great. In the beginning sparring sessions with experienced developers are most helpful, later on as the software grows in complexity, making it easy for people to submit a bug fix or contribute documentation and localization will be increasingly important. One person can only do so much (actually one person can do a lot, but why have all the fun by yourself :P)
• if it can't be a SaaS, updates should be as pleasant as possible
  little breaking changes, automatic update wizard, documentation on how to update from version x to version y (meaning every combination of every possible version update), but most people don't update their software which is probably because they feel interrupted and annoyed, or they've had bad update experiences in the past. If a user gets hacked because of a security flaw, they don't attribute it to their inaction to update the software but rather to the company who released the software. So they don't see any value in updates. Unless the update fixes something that has been a pain, or introduces something new that is really nice. But even then people feel aversion to the new and unfamiliar, most people like what they're used to. Actually just thinking about this, the software should probably be SaaS.
• if it can be SaaS, it should feel like users own the software
  Nobody likes being at the mercy of a higher power. Having the ability to change every users software (going as far as shutting it down) is very powerful. This should always be kept in mind. Don't make people suffer just because you can easily update and deliver your software (see principles higher up). It needs to be considered whether it should be allowed for individuals or groups of individuals to host the software themselves because this introduces the old pain point of people not updating the software, which creates support overhead and frustration. Will have to think about this one more and consider alternatives and their trade offs. Maybe a license that only allows using the software and offering a hosted solution if all changes are implemented in the open source version first and subsequently released into the hosted versions. The hosted version should never differ from the open source version for longer than x days (which means upgrading needs to be safe and straightforward). This license would also offer reasonable safety that design principle number one is always adhered to.
• the GUI should look harmonious and pleasant
  Change always makes people uncomfortable (I'm looking at you new gmail inbox and reddit redesign). Once defined, the style should change as little as possible or so slowly that users don't get anxious (see hacker news, google search, GitHub, etc.). Occasionally, the GUI should present something fun and unexpected that delights the user.
• the software should be efficient
  Proof of work from cryptocurrencies would be an example for what not to do. The software should use as little resources as possible (trade offs will have to be made of course). It would be great if people would only pay for what they use, which is the actual costs to run the software without costs of human labor.
• the architecture should emphasize simplicity
  This means the software should ideally only provide the features that will cover 80% of the use cases and solve users biggest pain points. Need multiple people in the same account? -> don't make a "team" feature, just make it easy for people to do what they've always done, share credentials (this might come with a trade-off in security, or more work to make sure the account stays secure despite account sharing, or requires an entirely new solution to this need). Again, user experience is more important than developer experience but if the app becomes a tangled mess, user experience will suffer. This will probably be the hardest to follow but I have a good foundation because I don't need to make money from this app.
• the software design should foster trust between freelancers and their clients
  Trust is one antidote to complexity creep, if real trust is established, entire features can be disregarded completely and the software can stay more simple. If safety measures need to be implemented because people don't trust each other, there's a higher chance of making the software more complex.
• downtime should be handled as gracefully as possible
  The app will be down. Ideally it never should be, but if it's down at a time where users really need it, it should be as easy as possible for them to see a helpful message or reach someone that can help them. Maybe the app can be so decoupled that the worst that will ever happen is some subset of features are not working any longer. Then it's conceivable that the UI elements for these features can display a helpful message that let's the user know things are being fixed and will be back to normal shortly but that they can use any of the other features of the app. If everything is down, maybe the 500 page should show a description on how to make an invoice using google docs, apple pages, or microsoft word.
• use shortcuts people are used to
  Starting with everybody's favorite cmd + z

Open questions:

• How to address different user groups (seniors, younger people), how should the UI be different?
• lambda functions? serverless?

Feature ideas:

• allow clients to set hourly rate freely or set any total price
• list projects the user (freelancer) is working on so clients can choose to help them out if they're knowledgeable and can help
• billing probably for the beginning at the end of the month