24 October 2011, 11:25
I have two lectures coming up in the next couple of weeks. Both of them will take place in Berlin and I am really looking forward to them.
the WUD network
First up is the world usability day (WUD). The date? Any second Thursday in November will do (the 10th, this year). I have been involved with the WUD since the first one (cannot even remember the year anymore), delivering lectures or leading a workshop, as well as helping to organise it. And so it is this year.
The Berliner WUD’s theme this year is Social Networks. I am always heavily involved with the topic‐selection for our WUD. But as the facilitator in the process, I refrain from voting for any one. Thus it was really a coincidence that earlier this year I worked on a social network, with unusuals, a startup here in Berlin. This hands‑on experience with a sprouting social network really piqued the interest of the WUD programme committee, so here we go. Here is the blurb, in English:
structured visualisation or simply being social,
the design work at unusuals.net
Earlier this year Peter Sikking consulted on the interaction design of unusuals.net—the network for advertising film professionals—who were preparing a relaunch. The work consisted of equal parts design process structuring; engraining social interaction; enabling simplicity; and visualising the industry network on any scale, from personal to global.
In his talk, Peter will weave these elements together, and show that it takes all of them to create a social network like unusuals.net.
Just the week after, on November 18th, there is the MobX conference. Very cool to be invited for this one, the lineup looks great. Thinking of a topic for my lecture, I first had to escape from the pattern that the other lectures had already set. Only then I was able to follow my intuition and arrive at the topic that was in a sense already sitting there, waiting for me to catch up with it. The MobX organisers thought it smashing. Here is the blurb:
mobile before and after January 9th, 2007
Love it or hate it, the introduction of the iPhone did completely reshape the mobile landscape. Peter Sikking, involved in mobile user interaction since 1997, would like to take this opportunity to review the world of ‘old mobile’: the environment in which it was designed; the interaction architectural aspects. What is valid and what has become obsolete in the ‘new mobile order’ that started with the launch of the iPhone?
Part two starts with the day of today and looks to the future. Does old mobile have a chance? What about hybrid, touch and type, devices? Peter looks at it, as always, from the architectural point of view.
In case you want to go to either event—and why not meet me there?—I would not wait with signing up, for the WUD or the MobX. Certainly for the WUD I can say that room will be scarce, for this theme and location. Better be registered.
If you cannot make it, then stay tuned. I will write up both lectures here. And already for one of them I can promise a final conclusion you would not expect.
10 October 2011, 14:03
Over the last year or two, we at m+mi works have seen a remarkable increase in projects with local startup companies. For us this is tangible proof of the alleged trend that Berlin is the location for your next startup. I can see the driving forces behind it though. Having set up shop myself in Berlin, I can only confirm the advantages and benefits of doing so.
1. do you really want to?
Do you really want your product—application, mobile app, website or online service—to be compelling and elegant to use? I have to ask, because a lot of folks I talk to say they want this, but in reality very few take the necessary steps to make it happen.
Starting with the right mindset (is the value in features or in user experience?); followed by finding the right people to design your user interaction and putting them in charge; then, when it is crunch‐time, standing by your user experience goals, instead of declaring them ‘nice to have.’ This is just a selection of what it takes.
If you are wavering at this point—or think you can cleverly bypass one of these steps—then you might as well stop reading, with the certainty that your product will never have a great user experience. Maybe you can make it regardless (‘if no competitor bothers, then…’). However, if you know that your success depends on your user experience, then read on.
2. you have a rare opportunity
At startups we regularly find the kind of environment that is conductive to the design of great user interaction. Working directly with the top decision makers; a lack of conservative and reactionary forces; genuine believe in the product; relentless focus on product inovation; a ‘can do’ mentality; knowing that only the best survive.
Add to this a product idea that must be innovative (‘me too’ or ‘feature parity’ equals death) and you can see why it can be exhilarating for us at m+mi works to work with startups.
My message to startups: you owe it to yourself to make use of all this energy. Unlike most other companies, you have the opportunity to produce something truly innovative, with user interaction that sets new standards. Grab it.
3. yet another development company
In some regards a startup is not that special. It is simply a software development company, which is governed by the same ‘laws of nature’ as any other software company. It is not that working at a startup gives a divine shot of inspiration and ability to developers, visual designers and product people for creating user interaction, is it?
The laws of nature dictate that if you want your product’s user interaction to be a hit and drive the growth of your company—instead of impeding it—then you need to involve specialists. No, the creative guy with photoshop is not it.
Similarly, going around friends, family and neighbours, asking them ‘here, try this’ or ‘whaddaya think?’ is not a usability test. Have an introductory talk with a usability specialist to find out what goes into testing of your user interaction. I am sure you will find it worth your while.
4. if you take UI seriously, budget for it
You are determined to take the necessary steps to give your product the user interaction it deserves. I think the following truism will not surprise you: you get what you pay for. Interaction architects are quite thin on the ground; we are usually busy; and we work at the top of the software development pyramid.
If you want a permanent interaction architect on your team, you are looking at making him or her a partner, with the equity share that goes with it. A person with the right ability—and experience—will know that user interaction is the one and only embodiment of the product, and will only accept a position where the accountability comes with the necessary authority: a ‘C’ position (CUIO?). As the startup grows, more junior interaction designers can be added. But the first one has to be a leader.
Involving external user interaction experts does take a healthy budget. The good news is that if you are familiar with the day rate of a good freelance developer, you will not be knocked out by what interaction firms charge. Bonus tip: the kind of visual designers or front‑end developers who say that they also do interaction design as part of their job, will be exactly the ones who can’t.
5. to save money, you can work more
An important asset of a startup is to compensate a lack of time, money, expertise or personnel by just working more, a lot more. I have used this fact to make a project with one startup happen. It turned out to be very successful and enjoyable. However, there are some hard limits to this approach.
Certain talents and skills need to be available at the startup to be able to take over a good chunk of the menial design and specification work. This is not always the case and it will have to be ascertained before a project starts if sharing the design work is feasible. Then, there is simply no substitute for expertise. Scaling back the involvement of experts simply scales back the depth with which the interaction challenges are met. You get what you pay for.
6. you got to have a vision
Creating good user interaction does not consist of applying some ‘divine’ rules, library patterns or platform guidelines. Also simply copying something that you like from another site or app does not get you anywhere. Designing interaction means creating the embodiment of your product and to help you with that, the interaction architect needs to know what it is.
A product vision is your short, sharp statement of what your product is. It answers three questions: what is the identity of your product; what are the core user groups; where is the end‑user value? The first thing we do in a project is to moderate a session where we help you to draw up your vision statement. Once done, it will be the fundamental basis for answering any interaction design question, our pact for the rest of the project.
If you fail to get your product vision together, then I am afraid your product is doomed. Examples of failing visions are:
- identities solely defined in a derivative way (‘like twitter with music, really’);
- user groups that are impossibly broad (‘everyone’) or schizophrenic (‘for baristas and nuclear scientists, yes’);
- only being able to offer features, when value is asked for.
But not to worry, it is rare for a vision to fail. And when it happens, it tends to be at big corp.
7. zealots, infidels and you
So you got your vision and—as I know startups—you are constantly ‘selling’ it to anybody who wants to listen; including yourself, to keep the faith. But wait, who is actually ‘buying’ it? Well, ultimately only those who invest in it. Either with capital (money, machines, bandwidth, etc.) or with a slice of their life (partners, working ‘for nothing’ for a while). Besides them, there are two more groups.
First there is the huge group of total outsiders to your startup. Talking to them is, at best, a form of market research. From experience I say: because they are not part of creating the future, they are a most reactionary force (‘micro‐blogging in 140 characters? no way’). The magic trick is to stick to your vision, but in the meanwhile filter the occasional nugget of gold out of this stream of feedback.
The second group are those—internal and external—who work with you on realising your vision, creating the future together with you. Are these people cynics, because they refuse to invest in your vision and want to be paid directly for their goods and services? I say: no, these people are very valuable as objective collaborators. Don’t take it as a rejection of your vision, they work with it every day. But without roze‐tinted glasses and no IPO on their mind, they are in a better position to see—and tell you in plain language—the reality of implementing your vision. Make use of their professionalism.
8. you have to build an organisation
Here is something I learned, the hard way: startups have, by nature, no track record of their capability to really develop and ship software. Yes, this is also true if one or two grizzled veterans head up the development. The first reason for this is that the organisation has to establish itself: procedures, communication, support systems, information flow, etc. The second reason is that it takes quite a while to find out if everyone on board is really up to the job.
As a startup you really have to take this into account. It starts with working on that organisation. Yes, even if there is only one developer. There is still information flow; bug tracking; an interaction design to be communicated; perhaps content or a visual design to merge. The one person responsible and accountable for building a software developing and shipping organisation is the CEO, and no one else.
Another way of taking all this into account is to plan with the overhead, delays and other surprises that are caused by both reasons above. With all that agile and iterative development that is in fashion at the moment, ask yourself what the dependencies are if one or two people are not able to deliver. I have seen processes like that completely unravel, with ugly knock‑on effects.
9. structuring is more than half the work
For any project interaction architects do, structuring the design process and implementing our methods is the backbone of our work. The feedback I get indicates that when working with startups, the value of this reaches the next level. I see two reasons for this.
First there is the factor of order. True, for just about any company we work with, our structure and methods supersedes a mostly haphazard and random UI creation process. With established companies, this comes in the form of process change. But with startups this coincides with the organisation building discussed above, and the clean‑cut structure that gets established is much appreciated.
Second factor is clarification. Working with a startup on their product vision; followed by compiling the functionality overview; then some user scenarios to represent typical use; it forces to make concrete what was only there on a subconscious level, or in a state of constant flux. Startups realise that this clarification work we do is a first and necessary step towards shipping an actual product.
10. you will have to manage
As you are building your startup, you are in a rapid process of transitioning from doing everything yourself to hiring professionals—internal and external—to handle all kinds of competences: product, interaction, visual design, development, testing, usability, sales, legal etc. Here is one that is sometimes overlooked: project management.
When you have picked the right people, they bring their skills and industry experience; they structure their work and act with authority—within their competence area; they know what it takes to get it done. But you will have to put them all together. Project management does not just happen by osmosis.
Building that organisation; realistic planning; keeping everybody on‑planning; dealing with contingencies; QA; multi‐platform issues; alpha, beta and rollout phases: you will have to manage it, or have a professional do it for you.
The proof of the pudding is in shipping it. Well, you know what I mean. A product does not exist until it is out on the market. And I mean shipping, not promised, announced or private beta. Now, a quest for perfection gets you nowhere. Question is: how much are you willing to give up to get it shipped?
My point is that you should not be staring at a feature list to find out the minimum you can bare to ship. Instead, think of minimum coherent user experience. If you got to be embarrassed when you ship your first version, let it be caused mostly by ‘missing’ features, instead of ‘good enough’ user interaction.
If you want your‐product‑v1.0 to have an impact and form a basis to grow, then its embodiment, the user interaction, should be designed, not an afterthought. So start small, that helps with getting it out; have the essence of your product designed and then ship it.
12. beware of strangers bearing gifts
There is quite a bit of support out there for your startup. University programmes, incubators, venture partners, business angels, subsidy from city, province, country and the EU. Perversely, some of this support comes with a serious helping of red tape. This can reach a point where the founders of a startup do not have the autonomy to act like executives and entrepreneurs.
I’d swear that the point of a startup is to innovate like no ‘normal’ company can. No naysayers playing it safe, no bureaucracy, no controlling. It means selling the vision to investors, then doing whatever it takes to ship it. And failing fast if the vision or its development is unrealistic.
Startups that live in a bubble, protected from harsh reality by a checks‐and‐balances bureaucracy, end up being humdrum R&D departments. They miss the urgency and agility that enable startups to ship great, innovative products, with great user interaction.
what type of interaction?
And that’s it for now. Maybe you expected something else, like tips about sign‑up forms, touchscreen finger grids, widget toolkits, the merits of toolbars. Actually, the twelve factors discussed above are a couple of magnitudes greater in impact where it comes to user interaction. Some of them are elephants in just about any software company’s rooms. Now what you need to do, is to return to tip one and ask yourself: do I really want to?
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
What is Peter up to? See his /now page.