Every interesting IT application requires many people to be involved—otherwise, it’s just a personal project. At the minimum, there will be:

• a user
• a programmer

and often people filling other roles are involved too, such as the following:

• client
• domain or business expert
• user experience specialist
• product manager
• graphic designer
• tester

Applications are expensive to build, so it’s necessary to ensure that everybody has the same thing in mind. The subject is usually complicated and abstract at the same time. Therefore, it takes considerable effort to communicate ideas among the people involved.

In this article, I’ll walk you through various tools you can use to communicate in your project successfully and to gather inputs from many people.

User story

A user story is a description of the system feature from the user’s perspective. It helps keep developers focused on what’s important—letting the users do something. Often, user stories are written following the same pattern. For example:

As a [role], I want to [action], so I can [goal]

Small, exercise projects could be explained with just a few user stories; bigger projects developed in a team will have multiple user stories added in every release.

As a developer, you will either get stories from:

• the client,
• project manager,
• etc.

Or you will get some description of the feature, which you will be able to paraphrase as a user story—creating an opportunity to check with the other side whether your understanding is right.

Example

If I were building the simplest example application—the hello world—my user story would be:

As a user, I want to be greeted, so I feel welcome

Even the simplest use case can be described this way!

Sketch of the interface

Computers are great for many things, but nothing can beat the speed and simplicity of the most basic design tool: a piece of paper and a pen. You can produce a sketch of an interface you have in mind within a few minutes—and as soon as you see some issues with it, start another interaction from scratch. You can do it as you talk or listen to your colleague—and add a visual layout to complement the discussion you have.

I see something in my head, you see something in your head—let’s invest a bit of office supplies to make sure we talk about the same stuff. And for remote meetings, you can:

• send pictures of your hand sketches,
• share an online drawing board,
• share the screen of a tablet on which you’re drawing

Example

Back to our example:

I hope you work on a bit more interesting case!

Wireframe

Wireframe is our sketch recreated in a design application, focused on transmitting the general idea as opposed to the exact look. It’s low-fidelity—nobody expects the final product to look exactly like this, but it’s more readable and easier to edit than hand-made sketches. With these kinds of artifacts, you can start formalizing your interface idea: show them in a presentation and don’t worry about contrast or handwriting quality. It’s still rather fast to create, so you can quickly show changes to everybody involved, making the progress visible.

I was introduced to this idea by the Balsamiq application. Balsamiq produces pictures in a very nice, handwriting-inspired style. Unfortunately, right now, it’s available only for a monthly subscription or a 30-day trial period—which makes it less suitable for sporadic users—for example, learners.

You can recreate a similar style with Excalidraw or using one of the many tools listed on AlternativeTo.

Example

Luckily, the use case I’ve picked is easy to show:

Mockup interface

The next step is to show exactly how the application is supposed to look. This is work for graphic designers. I’ve never done it myself, but I’ve seen people using:

• years ago, Adobe Photoshop, and
• most recently, Figma

If you are using decent defaults—for example, some UI framework like Bootstrap—you should be fine skipping this step.

Example

Back to the example:

My first Figma design!

Prototype

This is the first approach to implement a usable application. In the case of non-trivial applications, with some logic, it could be a quick and dirty attempt to partially implement and partially simulate a working solution. It allows for usability testing before building the real things—and before spending time on quality-related parts such as

• tests and
• covering all the edge cases

It’s useful to think about prototypes as disposable code. Depending on the number of shortcuts you took while creating it, it can be better to start the thing from scratch instead of refactoring from this state to production-ready code.

Example

In the case of my simple app, I can be sure my prototype is production ready. index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Hello World!</title>
  </head>
  <body>
    <h1>Hello World!</h1>
  </body>
</html>

Works as expected:

Even though the prototype code may be discarded, it’s definitely worth putting it to the repository, so here comes mine.

Share your project!

This article is the first in a series of articles about working on frontend projects. I know many of you are building multiple projects as you study, doing simple implementations of many project ideas. In my series, I’ve picked an elementary application because I want to go in-depth with all the aspects related to the project development—from the design phase to containerization and cloud deployment. Please let me know in the comments if something like this will be helpful for you. Hearing back from readers helps with motivation.

And if you would like to use this as a group exercise for you, then take the study application you are building, follow some tips from here, and share in the comments.