Tools

From Prototype Fund
Jump to navigation Jump to search

Here you can find a list of tools and resources that were either recommended by projects during their funding period or mentioned during coaching sessions and calls. The list is in no way complete - feel free to send your tips to the program managers and we will add them to the list!

This list exists only in English as it doesn't make sense to translate a list ;)

Design/UI

See also: Tipps von geförderten Projekten, Users&Communication

Collaborative tools

  • UI-Design and Drawing
    • Penpot is a FOSS-alternative for Figma, a UI design tool
  • Whiteboard

Visual Design

Color

Fonts

Icons

Branding

Logo design

Design systems and consolidation

Project management and coordination

Redesign & preparations for working with designers

Finding a designer

User research & journeys

Accessibility

Usability principles and rules-of-thumb

Guidelines

Evaluation methods

On finding out if your ideas work. Very often this is done too late – with paper prototyping you can run a simple evaluation within a few hours, so do test early and often!

Prototyping

  • Paper prototyping, a way to try ideas with users without needing to write any code. See paper prototyping on Wikipedia and an introductionary article on alistapart.
  • Concept prototype: Testing your idea when it’s still at the conceptual stage: Keep it basic, keep it at the big picture level (so users won’t focus on the finer details, like the color, design etc), use an exisiting product that is similar to get the users talking.

Analytics

Heuristic Evaluation:

Using rules to spot usability problems in a usage scenario; ideally done by several people.

Usability tests

In a usability test, potential users try to use an early version of your product to find potential problems that you need to fix. User testing is not meant to sell the idea to the users, it’s to gather data/feedback that supports you to continue product development, so use any resouces available as early as possible to communicate the idea.

  • Before testing or having a software, maybe you want to document user context and processes.
  • In general, it is better to do several smaller usability tests than a one or two big ones. Even small numbers of users can help to find problems. A classic article on this is "Why you only need to test with 5 users"
  • You do not need an almost finished product to test (the earlier the better, actually): You can evaluate a single feature (see tracer bullet development), a mockup (see penpot or figma) or a paper prototype.
  • Role play workshop content for learning how to do user testing. See also this article on wireframing.
  • The book "Rocket surgery made easy" (Steve Krug) describes usability testing (and recruiting for- and communication of it).
  • The System Usability Scale (SUS) provides a “quick and dirty”, reliable tool for measuring the usability (measuring sounds cool, but it only makes sense if you have something to compare it to, like a previous measurement!)
  • A Dev's guide to Usertesting, made by Superbloom, has resources that can help OSS tool teams start to do user testing and usability testing in their OSS tool projects either with or without a designer helping out.
  • User testing examples for the process and design documentation. Here is also an example video for a usability test.
  • You can get free access to an otherwise expensive suite of user testing tools through UserTesting.com’s social impact program, OneWorld (Note for usertesting.com (and similar products): You won’t get a lot of people from marginalized communities e.g. because payment needs a bank account or credit card etc.).
  • Thinking out loud - encourage users to think out loud to get their though process as opposed to their opinions.

Project management and planning

  • See also: Tipps von geförderten Projekten →Managing teams and projects, →Managing time
  • Communication is key: People on the project should have a common understanding of what is going on and what support others need.
  • Be aware that project management methods need to fit your needs and context: If you are a 3 person team, but the method demands a build engineer, a facilitator and some more roles, it might be good for a big company, but not for your prototype project!

General overviews

  • Book: Ship It, Richardson/Gwaltney, 2005 – good overview with focus on software projects. Similar to Pragmatic Programmer it is written as a toolbox, so you can ignore or change what does not fit your needs.

Methods, Tools and frameworks

  • User Story Mapping is useful to plan which features to work on first. It can be useful alone, but it is particularly helpful for working in teams. There is also a book: User Story Mapping by Jeff Patton, 2014.
  • Kanban is a relatively lightweight project management method. Think of it as a slightly expanded todo list.
  • Stand-up-meetings usually happen daily: Meet with the team, everyone tells everyone else the answers to these 3 questions: What did I do since the last stand-up? What do I want to do today? What is blocking me? Keep these short. It is meant as a mutual short update. Don't go into discussions, note questions down and ask them after the stand-up.

Tools

  • Wekan, Taiga and Kanboard are open source project management tools based on the idea of having virtual cards or sticky notes. If you already use an issue tracker or git hosting, a similar feature might be already implemented there.

Writing maintainable Code

This is not about writing code in a particular language, but about writing code that meets your user’s needs and which can be changed if needed. Like with project management, try to find methods that are helpful for your project.

  • Tracer Bullet Development is a method to get a working version of your software quickly. This allows to evaluate code architecture and user interface early. The method is described on this website, and more in-depth in the books "The Pragmatic Programmer" and "Ship it".
  • The Pragmatic Programmer (Thomas/Hunt, 2020) is a good general introduction to professional software development: Keeping code readable and easy-to-change, learning requirements, utilizing unit- and property tests, basics of securing applications. There is also a German translation ("Der pragmatische Programmierer").
  • Weniger schlecht Programmieren (Passig/Jander) ist "Pragmatic Programmer" ähnlich, fokussiert sich aber mehr auf Code und weniger auf Projekte.
  • Refactoring Guru has a lot of resources on common ways (patterns) of how to approach particular problems and how to improve existing code to make it easier to read and to change (refactoring).
  • 12 Factor app is less about code than about running the code in a way that it can be easily and safely configured, ran and monitored. When you create your project based on modern frameworks (i.e. Laravel) it will often follow such principles.

Markdown & co

  • Markdown table generator
  • Pandoc converts various formats (like markdown, HTML, LaTex, docx,…) into each other. Great to build simple tool chains around documents.

Funding & Sustainability