Work

Securige operator user interface

I’ve designed the UI for the panel protection program Securige. It’s a program where operators see if someone’s broken into your apartment and send the rapid response team if they have. That’s what it looks like:

My favourite moment of the project was when I was sitting at the operator’s post quietly (it was the condition to let me in), and the operators are like “if you have questions, just ask!”. And so I started asking. That’s where I’ve learned why the keyboard is almost never used. Otherwise I wouldn’t have come up with the Fitts-law-optimised search bar on the left.

Also, when I asked what irritated the most in the existing program, everyone said: “it’s fine”. But when I gave examples of possible improvements, they said: “wow, can this be done?”.

Very interesting project. A whole book on user interface can be written just on the examples from this one. Read a more detailed description.

2017   projects   user interface   work

Why I don’t call myself a “UI/UX” designer

Many of the things I do are considered a job of a “UI/UX” designer. But I haven’t ever called myself one.

That’s because the term “UI/UX” is badly designed: it’s tasteless and vague.

Tasteless

The abbreviations are used in science and tech, but when normal people talk, abbreviations are out of place. A good user interface is humane.

The way this abbreviation is constructed is wacky. First, it includes the word “user” twice. The good designer would not put a word twice where once would suffice. Second, it abbreviates “experience” with X instead of E. This comes from cheap marketing, where X used to sound “cool” and “trendy”. When a designer uses it, I feel like they disrespect the user and have shallow knowledge.

Vague

There’s a “/” in the middle, whose meaning is unclear. A slash usually implies an exclusive or. So does this mean “UI or UX, but not both”?

Good writers use conjunctions, not slashes. A slash is a way to slam two pieces together without thinking what sense the combination makes. This is not how you design a good user interface though.

The lack of taste and inability to communicate well are not the qualities of a good designer.

See also: Guy English on UX

2017   design   language   myself   work

The “Buy” button should always work

Here is one lesson I have learnt working on Envy, a cool Hawaiian car rental.

On a car page, there is a yellow price tag with a “Rent” button:

The “Buy” button should always work

A typical way to get to this page is the following. On the front page a client chooses the desired rent dates, clicks “Find”, then selects from available cars. It is possible though, that by the time the client selects a car, somebody else books it already. Or the client reloads the car page in a couple of days, and the car is gone. One way or the other, a client can end up on the car page with the pre-selected rent dates, for which the car is no longer available, and they won’t be able to rent it.

Also, on the front page we show the best cars we have. A client can click any of them and get to its page, having skipped the dates selection altogether. In this case, the dates won’t be specified, and the client also won’t be able to rent the car. We didn’t want the client to be confused by the disabled “Rent” button, so in addition to the front page, we put the dates selectors to this price tag itself.

I presented the design of the car page to Ilya Sinelnikov (co-creator of Envy) and was talking about the price tag.

I said, we didn’t like that the “Rent” button is disabled sometimes: the website is there for the people to rent cars. But how can you rent a car which is taken by someöne else? At first, we thought that we could automatically change the dates to the nearest available ones. But it can result in a disaster: what if the client doesn’t notice the change, pays for the rent, comes to pick-up the car, and learns that we don’t have it? I said, we were also thinking about some tool to explain the problem and help the client change the dates, but there was no chance to make it on time for the website launch. So, I said, for now I suggest just disabling “Rent” the button in this case.

Also, I said, a car could become unavailable while the clients looks at its page. Therefore we needed to re-check the availability after the “Rent” button is pressed, and inform the client of a problem, if it occurs. For now, I said, we’ve designed this error page. In the future it would be better to suggest a date change or offer another car. But this is also not going to be implemented by launch...

Ilya interrupts: “To hell with the dates, let’s just make the button always enabled.”

What? There can be no car for the client when they come.

“The client is willing to pay us money”, Ilya says, “and you prevent them from it by disabling the button. This is inefficient. Let them pay, and we’ll sort it out”.

And then Ilya enlightens me. Envy as a business must be able to sort this out anyway. It is possible that a booked car is not available for the client, say, if the previous client breaks it, or whatever. In order to make the client happy, Envy offers them a better car for the same price.

For Ilya, it all appeared as if I was trying to stop his client from paying him money with my UI. But from the business perspective my UI consistency hurdles are insignificant. Dates have accidentally overlapped? Oops, sorry, here’s a Mercedes instead of a Ford, no big deal. In the worst case, if there’s a super-picky client who won’t take anything but the very car they’ve chosen on the website, we’ll return the money and apologise.

So we made the “Rent” button always enabled. If by the time the client clicks it, the car becomes unavailable for the selected dates, the manager gets a notification about a problem, and it is their job then to contact the client and agree on a new car or dates. And if the dates are not selected at all, clicking “Rent” moves the focus to the dates fields and opens the calendar, so that the client knows what to do.

Principle: the “Buy” button should always work.

2016   Bureau   design   service design   web   work

Envy.rent calendar

We have recently published the work we have done for Envy.rent, a cool Hawaiian car rental:

Check it out.

Here is one detail that brings me joy. It’s the calendar where the client selects the rent dates:

Notice how the sticky part works. The heading moves up and fades out, the weekdays come to stop, and the ruler under the weekdays stretches to touch the edges, thus separating the sticky part from the moving part. There is also a nice time slider.

The calendars for start and end dates drop down simultaneously. This is counter-intuitive, but very convenient.

2016   design   user interface   work
2015   design   work

Getwear

Getwear has launched. It’s an online designer jeans store, a new site made in the bureau art directed by me.

Select from a wide range of models or make jeans according to your taste in the Constuctor. Add embroidery, distress, draw flowers with a pumice, – or merely choose another style of back pockets. Buy the jeans for yourself, then put them on sale in the store. The best jeans get the most votes and end up on the front page, other visitors buy them and you get a cut of money.

The best feature is Custom fit. It’s like having a personal tailor, except that you take the measurements yourself. The site helps you though: it guides you with instructions, pictures and videos. Then you add your special requests and order the jeans. Getwear will change your jeans free of change if they don’t fit perfectly.

Also, we’ve designed the shopping cart right: you specify the delivery address right there and you see the real total below. Not some mythical “subtotal” value that will change after they add delivery later, as they do in other online stores. The real total, straight in the cart.

Try it here: getwear.com.

This was an incredible project. The task was great, the client relationship was great. We’ve used all the best work principles and we’ve followed the plan rigorously, even if it meant sacrificing some of the ideas. And we are content with the result. I sincerely wish Getwear all the best.

The project is another illustration of how pictures aren’t everything. Even after every possible screen have been done in Photoshop, after every possible page has been marked up in HTMLs, we had had meetings several times a week and had exchanged mail like crazy. There were a lot of questions and decisions. The design questions and design decisions.

The time after everything has been almost done and when everything is almost ready for a launch is the time when most of these decisions are made. It’s the time when you want the designers to be there. The clients who end their relationships with designers and think of design as “finished” before this crazy time are making a big mistake.

2012   design   projects   work