I want to make a web app for tracking personal development metrics.

The “OKR” stands for

• objectives (O)
• key results (KR)

and you can learn more about theory on Wikipedia about OKR.

Right now, for this project you need:

• curious mindset
• a Linux box (VPS)
• shell access to your VPS
• bit of interest to learn Rails web development

This blog post tells the story of making the app, from ground up.

Designing brutally simply User Interface

Since OKR is two parts (Objectives) and Results, we might need also two “things” in the UI. Whether we use separate Views is a matter of design.

Eternally great UI design principles

I love and aim to achieve:

• UX which wastes zero extra time of users
• help available, in app, on-the-spot
• so simple design you don’t need actual “tutorials”
• don’t let users “hang” in places which could be most non-obvious

A few words of users who “hang”

I was once in a project where a really “non-obvious” thing became blocker: the log-on page. As a result, a portion of users simply could not use the app at all. This is obviously bad. (UserFocus site calls this ‘critical’ usability problem; there’s a bit of variation on terminology).

This taught me a lesson: badly stuck users may be quiet, they may never get a chance to voice their concern. In commercial SaaS software, users on trial plans, who are just beginning to explore the beauty of your app, may not have the willingness, means or energy to inform you of getting stuck.

Thus it is important to detect stuck users.

Simple acknowledgement gives you data

You might be able to add tech that detects stuck users! For example, in your post log-on landing page (the first View ever for new user), you can ask.

Ask the user to acknowledge a simple Welcome message or View. Make a “tickable” (“I’m here, all good”) sort of welcome screen. Heck, we can do better: it can be just the app sending you, developer, a signal that user X has reached landing page. So we don’t need to directly ask users in this case.

So there we got two alternative, natural, simple methods of getting a signal back to you, from your users.

early View design: logon + 3 views

Rails follows the MVC paradigm. This calls for us to define what the ‘V’ (Views) are. We can be rather relaxed at this point. Just helps to know terminology, and adapt to future needs by putting the basis down right now.

Our app Views will be:

• logon
• Design View
• Data entry
• Results View of a finished Phase

That’s it. We got basically 3 “actual” Views, plus the mandatory logon view for logging into the application.

Design View is used before the beginning of a new measurement period. Here user can choose, what kinds of activity will be tracked.

Example of a simple tracking instrument

The instrument is just a name, eg: “hoursWorked”. An explanation can be added, so that user understands (and remembers in the future) what exactly this instrument measures. We could add “Hours put into learning and doing fullstack development” as the explanation for our simple instrument.

Especially data entry should be very simple. Navigation to most common Views should be short and simple to understand at a glance.

Generic UI rules

• We do not allow changing Objectives during a measurement period
• Objectives can be copied to next period
• Objectives can be CRUDed during Design Phase
• An Objective line contains ‘key’, explanation text, and Type
• We will call a Objective line “O component” from now on
• Key types are limited to one type at beginning, a Number

So, what this turns into for human beings, is:

• User starts with Design phase
• Objectives are defined
• An objective contains always 1 Key to track
• Key can only be a Number

Entry view (user point of view)

• entry happens daily, preferably
• user can enter data arbitrarily to any date within the active Period
• click on a date in calendar view, OR box in Period timeline
• enter data
• once all data is entered, user clicks on ‘Finish period’
• user has the responsibility for calling a period “finished”
• after Finishing, the Results View is shown
• user goes then back to Planning