Not Even Wrong – The Soulless Professional

October 2014
Stockholm – @ Valtech office

There are things that will awaken the warrior in me and spur me to take up arms and go to war. And break things. There are times when I want to tell people that they suck harder than a collapsing star. This happens when people I care about are not treated with the love, respect and care that I feel they deserve. There’s a reason why people are treated badly. So today, I will talk – or rant rather – about the root cause of that behavior. I will talk (with almost no structure at all) about professionalism.

Professionalism has everything to do with appearances. I’m quite certain you’ve come across situations where people have expressed irritation, or even anger, because something happened that made them “appear unprofessional”. Key word here being “appear”. For a professional what other professionals think of them is more important than anything else. Because how they are thought of is who they are. They accept that as a truth.

Professionalism then, is a mold into which we as individuals – with a varying degree – wish to fit. It comes as no surprise then, that the last thing a professional person wants, is surprises. As a professional, you will make your plans and forecasts and predictions. You’ll present them to people above you in your hierarchy – a hierarchy that you, by the way, see no problems with as your purpose in life is to climb that golden ladder. Eager to impress those above you, you make promises and assertions. In order to achieve your goals, you make threats and accusations. You instill fear, uncertainty and doubt in everyone “below” you on your golden ladder.

Obviously, for you, there’s no room for surprises. So when the fundamentally unsurprising reality still manages to both happen and surprise you, you will disregard the basic nature of things: existence is a complex, changing, chaotic and strange thing that you quite honestly don’t know frakk all about.

So, how do you handle this complexity of reality then? You don’t. You disregard it. And you do so either knowingly – which is evil – or unknowingly, which is ignorant.

The concept of professionalism hates surprises. When surprises happen it must have an explanation. The explanation closest at hand is that the other players who are involved in your game are simply “unprofessional”.

The concept of professionalism creates roles that you feel obligated to play. This causes a great disconnect between your authentic self and your work identity. This separation from wholeness causes tension. That’s why you’re a nervous, angry, frightened and neurotic a-hole towards anyone who can’t be of service to you in your climb towards the top.

The concept of professionalism promotes activity goals over outcomes. This is not only troublesome because of its alien mindset, it also causes a lot of old fashioned waste. A lot of stuff that shouldn’t really be done at all is done under the flag of professionalism. I call this “playing office”. You can easily tell when people are doing it. It truly resembles the games one played as a child, strangely imitating how grown ups behave.

The burden of being professional, coupled with the core belief that all it takes is hard work, also creates incentives to cheat, once one discovers that hard work is not enough, as anyone who is involved with complex work will soon realize. This is why projects can finish on time (activity), yet deliver no value whatsoever (outcome). This is also why so many products, services and experiences suck so very, very much. Because no one cares. It’s not professional to care about stuff that is not listed in the soulless, heartless manual of professional behavior. A professional will go above and beyond when it comes to keeping up appearances and reaching activity goals, but will not invest any passion in outcomes.

The concept of professionalism resists change, because change implies that there might not be anything for you at the end of that ladder that you’ve made it your life purpose to climb. And you’re right about that, by the way. There won’t be.

The concept of professionalism rewards acting and punishes thinking and questioning.
The concept of professionalism rewards conservatism and punishes risk taking.
The concept of professionalism promotes ego over teams.

For those of us who have chosen to embrace authenticity, this professional behavior causes other kinds of tension. The feeling for us is that we enter a theatre every time we find ourselves in such environments, and the show that these professionals put on feels both awkward and alien. We feel confused. Who the are these people? Why are they talking funny? Why are they trying so desperately to sound smart?

If we use the terminology of Frederic Laloux we might say that the mere notion of “professionalism” is a lingering leftover from “orange” organizations and the world view that persists there. If we believe that organizations over time move towards “higher” evolutionary stages – and we consider this a good thing – I put it to you that the concept of professionalism is an idea that slows evolution down and is basically holding the whole organization back.

In later posts we will examine the tension, the nervous and anxious behavior of “Green” organizations, which seems to me to be a direct result of these old concepts remaining as archaic mental models. If we view organizations as organic systems, professionalism is one of the concepts that the systems – driven by new values and ideas – is working hard to reject. The difficult process of discarding these concepts might very well be the change that has to be facilitated and endured. It won’t be pretty.

And you know, all this “new” stuff. Authenticity, passion, beauty, creativity, higher purpose and *gulp* talking about your feelings, hopes and dreams. Being human. It’s not what you signed up for. Because all you know how to do is be professional. But  you need to hear this: The current market value for “professional” is not at all what it used to be. And in the future of work – there won’t be a market at all. The clock is ticking.

In summary:

The concept of professionalism promotes faking in a world that craves authenticity. With the mask of professionalism to hide behind you can feel safe as long as you stick with the rules. Professionalism is often defined as “by the book” behavior. So basically, you’ll be rewarded for “playing office”, with the bonus opportunity to label those who find novel ways to pursue value as “unprofessional”. As such, the concept of professionalism legitimizes the confusion between activity and outcome.

And that’s #notevenwrong.

Earlier post on Not even Wrong

Not Even Wrong – Wheelan, Integral Theory and the evolution of organizations

October 2014
Stockholm – Papas Deli

Perhaps you have, quite like me, felt the frustration of observing group behavior through the lens of the IMGD model of Susan Wheelan. How does one go about establishing which phase a group is in, when the group does not have a voice, but consist rather of a multitude of voices, which can with varying degree of sophistication express their own understanding of where the group is at in terms of “stages” of group development. Sure, you can assess this from the outside, looking at actual behavior and listen in to how the group interact and solve problems, but the challenge remains.

So then perhaps you have, as I have, come to terms with the fact that the answer to the question “which stage is the group at when the separate individuals behave in ways that are congruent with different stages” is that the group can be at several levels simultaneously and that individuals and the whole group can move between the stages depending on time, situation and context.

This is fine, the model is still very useful. It is actually the tension between individuals at different stages that create the conflicts that need to be resolved in an amicable manner in order for the whole group to evolve.

The tricky part here is that people at different stages have different ways of dealing with conflict and tension. This then, is the challenge of group development. And this is what makes it so hard, yet so rewarding when it finally falls into place.

With this background established, we move on to Integral Theory, which – as Frederic Laloux demonstrated rather convincingly in his wonderful achievement “Reinventing Organizations” – is a rather useful model to explain the evolution of organizations.

When we talk about evolutionary stages of organizations, we can make a similar observation to the one we did when discussing IMGD. Different individuals, or even whole departments, can be at different evolutionary stages at the same time, within the same organization. This too creates tension and conflict, and this too needs to be resolved in an intelligent way. Anyone who has ever tried to promote Agile/Lean values and thinking beyond the “software department” understands how challenging this can be.

Even though this is a rather banal realization, as any model that proposes defined stages of evolution or development will have these issues hard coded within the very structure of the model, I have found it a valuable thinking tool.

If we turn now to John Hagels “Passionate Explorers”, the wonderful “Rebels at Work”, or any other description of progressive change agents, we know that the frustrations that these pioneers experience are very real. Many of us have felt or feel that we bang our head hopelessly against the unmoving concrete walls of “the old ways”. The fact that the departments or people in the organization that belong to a “lower” evolutionary stage still pay lip service to the ways and values of the “higher” evolutionary level (because it’s fashionable, you see) well that just makes it even more difficult.

The only way I know how to make people aware of when they’re not living their own espoused theory is to expose them to this reality, and this might not be pleasant conversations to have. Or even more troublesome, these conversation are often hindered by they way organizations are structured. This is precisely why successful change initiatives are almost always initiated at “the bottom”, but most certainly need the involvement of “the top” in order to succeed. We must not underestimate the cultural influence of an executive whose ideas and values belong to a “lower” evolutionary stage of organizational development.

In my experience, getting people used to the idea that there can be no action without theory, is a good start. You DO behave certain ways because you DO have theories about the nature of things, be it people (theory X / theory Y) or Organizations, leadership, management, purpose of organizations and businesses. These theories might not be known to even yourself – which is why reflection,  introspection and self-leadership must be promoted.

As always,the journey starts with someone taking the leap, and kickstarts the spiral of openness and trust.

Earlier post on Not even Wrong

Not Even Wrong – Thoughts on levels of abstraction

October 2014
London – The Hoxton

I have at times been accused of “being too logical” in my thinking, not allowing for other world views than the logical one. I can understand why such accusations exist, yet I am not entirely sure that those who claim that my disposition lean too much towards logic quite understand logic. I suspect at times that when they say “logic”, they mean “think”, with the opposite being “feel”.

I suspect that this is said by people who in their minds feel that they place higher faith in “intuition” than they believe that I do. With your permission, I will float my intuitive idea that several of these appeals towards the intuitive that I’ve come across have been nothing less than under-the-surface accusations leveled towards me to mask sloppy thinking.

I have on occasion found myself in situations where ideas have slipped through bouts of prioritization and ended up existing in my world as “a thing we’re doing”, and on examination the people behind these ideas cannot really explain what the idea means. And it follows then, that these people lack a shared understanding of what it actually is that they’ve prioritized. And yet, they still managed to prioritize this idea above all other ideas. And when I say that they cannot explain their own idea, I’m not talking about granular details of how the proposed idea might work. I’m talking about a lack of really high level understanding, as in: IF we do X THEN we believe Y will happen AND that outcome is desirable to us because Z.

If you cannot clarify at least this much inside your own head, then you cannot really make an informed decision about it. Perhaps, one might argue, it is the problem that the proposed idea is assumed to solve that is really being prioritized? If that was so, I would be happy as a clam. But I fear we’re not so lucky.

Could it be that a proposed solution to a problem is necessary in some quarters in order to explain and understand the problem itself? In some weird sense, that would be like a wonderful new version of backcasting, which could probably be a fun way to generate ideas. But alas, I’m pretty sure that’s not what’s going on.

This forces the question: which level of abstraction are you comfortable dealing with? What would make sense to me would be to make a full stop with the prioritization of ideas at the highest level of abstraction and start prioritizing problems we want to solve. Or, if you’d rather work from another angle, prioritize the outcomes we want to reach.

The levels of abstraction could be ordered in an hierarchy like this:

  • Highest level: What do we as an organization assume is our most important problem to solve?
  • Mid Level: Which outcomes do we assume solves this (these) problem(s)?
  • Low Level: Which actions do we assume takes us towards this outcome?

At a team level, you might have come so far as to have the team and the sponsors prioritize wanted outcomes – described in terms of effect. This works well, but we can do better. Usually, the team is at the lowest level of abstraction, and inevitably, the highly intelligent people in the team will wonder about the reasoning that took place at the higher levels of abstraction. Especially in a capacity constrained system (as all systems are) where the notion of alternative cost has been established as a way of thinking. So I think that techniques and methods like impact mapping and the like can be rather disruptive, once the thinking takes hold. It puts pressure higher up in the organization, because in traditional organizations, the highest level of abstraction is the domain of “top management”.

So, desperately searching for a red thread here. What I’m saying is this:

If you still work in a top managed organization and feel how the people “below” you in your hierarchy is starting to ask rather intelligent questions, please don’t tell them to think less and be more intuitive (like you). Intuitive is not the same as sloppy thinking. Believing that you can cover up your lack of clear thinking in the guise of intuition is #notevenwrong.

As I see it, you have two options:

1. Read up. Shape up.
2. Involve the teams in “all levels of abstraction”-problems.

In my mind, both options will eventually take the organization to a better place, but I do most certainly favor option number two.

Forward: Defining a desired future state and then closing the gap is what I would call a core Systems Thinking practice. Another way – and some would say a better way – to tackle things would be by way of Complexity Thinking – which we will have to return to in another post.

Earlier post on Not even Wrong

Not Even Wrong – Initial thoughts on strategy

July 2014
Stockholm @ the office

It’s been an interesting summer of reading. I was on holiday after all, so I gave myself a long leash and permitted my mind to wander. I ended up investigating my hunch that the way organizations think about strategy can have a profound impact on how they think about all the other aspects outlined in my model-in-progress. This is most certainly not a revolutionary thought, yet I felt I needed a bit more background on the very concept of business strategy to better understand the mechanisms that I sense are in play. I have a feeling that the underlying world view that constitute the basis of strategy is a bit of a blind spot for many organizations, to speak in terms of johari windows and all. I’m basically suggesting that many organizations unknowingly embraces strategic thinking that is based on world views that are not congruent with the world view of the organization.

This research led me down a path where I explored the history of business strategy, rather than the practice of business strategy itself. Mintzbergs Strategy Safari and Walter Kiechels Lords of Strategy were great companions on the journey.

On this journey, to my great and admittedly smug satisfaction, I found ample evidence supporting my long held belief that business strategy as a concept rests on rather shaky foundations. As you may know, there are several schools of strategy and they cannot seem to agree with each other on even the fundamentals. They are, as one author remarked,  “remarkably inconclusive”.

For anyone interested in Systems Thinking and Holism, the conception of business strategy becomes the starting point of it all, as every initiative or plan designed by the organization flows from the strategy – and more importantly – and this is my point – the strategy therefore carries with it the underlying beliefs that is allowed to guide the strategic process further into the fabric of the organization. It follows then, that identifying how the organization thinks about “strategy as concept” is a way towards understanding the fundamental world view that will, via the strategy, permeate the entire organization. I would venture a guess that this is not something that all too many organizations sit down and have a chat about, which further suggest that these underlying mental models and world views are left unexamined and most likely unknown to the organizations themselves.

Researching how the idea of business strategy itself –  and the later different flavors of strategy – emerged is immensely entertaining. For you who are happily unaware, suffice it to say that had you been there in the 1960’s when the idea of business strategy was conceived (in a joint effort of the management consulting firms and Harvard Business School) I would have excused you for remarking rather irreverently “Wow guys, you’re just making this shit up as you go, don’t you”. Because they were.

Fast forward a few years, and I would not have admonished you for saying “Wow guys, these things that you propose, they don’t really work do they?” Because quite often, they just didn’t.

One major take away from these studies is how severely  a classic prescriptive strategy mindset conflicts with the strategy-as-learning perspective. Implicit in the prescriptive schools of thought is the idea of strict hierarchies, top down, command-and-control and other – from my perspective – unwanted elements. The question I’m exploring is to what extent – if at all – the organizations’ take on strategy can be a constraining factor in our drive towards change and the future of work.

Further more, if the idea of generic prescriptive strategies is firmly in place in the minds of managers, there’s every reason to suspect that the dangerous idea of generic best practice also lands in fertile soil. The idea of organizations as complex adaptive systems finding themselves well within a complex context must seem awfully alien to such a mind.

To sum up: There’s a potential mismatch between the world view that created some of the strategy ideas now in use, and the actual world view of organizations. This might create dissonance. And as the novel practice of business strategy was exported to all corners of our globe, that movement seem also to have exported a set of beliefs and values that I deem to be detrimental to the idea of the modern workplace.

One might even say that they’re #notevenwrong

Earlier post on Not even Wrong

Not Even Wrong – Reality Check V: Guest Post: The biggest lessons from a successful software project

July 2014
Stockholm @ the office

Yet another great post from the Team that brought you the new Hemnet Map Search. This time by Stefan Lindbohm. You can find the original here

The biggest lessons from a successful software project

In my years of working with software projects the one thing I have learned is that doing software projects is really hard. Probably zero projects I have been part of or heard of has delivered their value, kept the quality to a standard everyone is proud of, launched on time and had a team of happy people through all of it. Recently, though, I was part of project that did just that. An actual real life professional software project that was deemed successful by both the team and the stakeholders.

I work at Swedish real estate site Hemnet. We are a company of about 50 people with about 15 people working in product development — mostly developers plus a few designers. Being a small company means we are close to management and all fill a bit wider roles than in larger companies. The biggest challenges in our organization has been making priorities and following them through. This heavily influences where we have put most of our effort and where we have made the biggest lessons making, though I think most of it can be pretty broadly generalized.

The team consisted of one UX designer, one graphics designer, one business analyst, one dedicated developer and me as team lead and part time developer. With the team of 5, we switched map providers, created a solution to render 100 000 hits on a map simultaneously and designed and implemented an all-new view for searching on maps. We did this in just 6 months and, from the release date set in the beginning of the project, slipped only one week with being fully rolled out.

Before we get in to what did matter, let me point out that you can Scrum, Kanban or Scrummerfall all you want without getting much of results. It’s easy to try to change the internal methodologies of a team because that’s something you’ve got complete control over. The biggest challenges though, are in getting the right conditions for the team and within the organization. Only after that is settled does methodologies begin to provide real value.

Here are the biggest things that made the project succeed.

A team with power to do its job

This is where everything begins. Way too often, projects are spread out over departments and even split in sub-projects over different departments. The business side is done in one project, handed over to a design project and then handed over to a development project. And even if that is not the case, people are still spread out without good means to focus and communicate on the project. This completely kills the common understanding and collaboration within a project.

Our team was created with exactly one premise: the goal of the project. We were to create the new map search experience on Hemnet. How would it look? Find out. How would it work? Find out. What would it even do exactly? Find out. This was absolutely crucial in enabling us to do our work — we are product developers and excel in solving problems. Based on the goal, the team formed the plan to do it, the concrete requirements and features and did all the design. Except for getting the rest of the company to buy in on our plan, we were never in need of someone else’s decision.

This of course requires the team to have all the competencies needed to get the job done. Having a team with a common understanding from start to end has incredible value in ensuring everyone works on the same thing and towards the same goal to create a cohesive product. In our team, having our business analyst from start to end allowed us to not stray away from business goals, and having everyone with from the beginning ensured we all really understood why the heck we were in this to begin with.

One of the factors we all appreciated the most was being all together in a room dedicated for the team and the project. If you are in an office, the change from being just one room apart is a huge boost to the social aspects of the team and the collaboration made possible by putting sketches up on the wall and just leaning over to talk about something is invaluable.

Making sure of a stable team with the right conditions is where everything begins.

Awareness of what could go wrong and preparation for it

Things always go wrong. The problem is that we more often than not ignore this and just plan for the best. This results in everything going to pieces when an assumption turned out to be wrong or an unforeseen problem arises. As a result, projects usually hit a point where everyone gets uncomfortable over something that went wrong and starts arguing over how to proceed — a situation where exactly nobody has their best ideas.

We spent a lot of time in the beginning of the project trying to figure out where things could go wrong. Being aware of the risks is key to being able to react in an intelligent way when something eventually goes wrong. In our case, we identified where users were most likely to have a hard time with the change and what business related key measurements we were most likely to impact. We completely shaped the project around the risks and made sure everyone understood and were prepared for the things that could go wrong. This helped us adapt continuously and completely avoid disasters, both in the product itself and among people in the company.

The plan we made focused on the key features that would be realized in the project on a higher level. This allowed us to cut the right corners in times when time started getting sparse while still delivering the value promised. We also spent time discovering where scope creep would most likely pop up and discussed these points beforehand. The things we agreed on not doing were then part of the plan. Designing the plan in terms of general features and including the things we would not do was a key tool for us in delivering the project on time.

Plan as much for the risks and the things you won’t do as the things you will do.

Collaboration outside of the team

All developers have been in projects where requirements and conditions change over their heads. A manager changes his or her mind on something too late in the project or another project gets important and starts snatching people. This is one of the most effective ways to demoralize a team trying to make something great and is probably also the most common way I have seen projects go out of control. The problem here is that managers often have no ability to make sense of cryptic scrum points, refactorings and vague descriptions of what is done and what isn’t, which forces them to make decisions with effectively no information on what they are deciding on.

First off, we put a lot of effort in communicating the plans for the project. We made sure everyone with the power to change our faith were fully aware of the plan, including what we would do, what we would not do and what we needed to complete the project. We did this early enough that we still could change everything and made sure that all stakeholders had their say before nailing it.

During the project, we continuously discussed any change that would affect stakeholders with them and held recurring demos open to anyone in the company. This allowed us to work without dropping anyone’s perspective. We had a number of small changes come out of this that would have gotten into big problems if they wouldn’t have been revealed until the end of the project.

Keeping managers and stakeholders in the loop is key to having the project stay it’s course.

There isn’t ever a silver bullet with these things. These were the biggest contributors to this specific project being a success. Even though I have reason to believe they would help significantly in many situations, a project always have to start with the people and environment where it will live.

We have the brilliant Thomas Lindqvist as our full time coach working on process and people since two years. This project is the result of those two years of experimentation and much of the reasons why it succeeded are the brainchildren of Thomas’ continued thinking on the matter. This may seem too obvious, but the best way to get better at process is to spend time thinking about it and improving it.

If you are interested in more on this particular project, Thomas has written on the “post-mortem” retro we held with the team, our graphics designer Daniel Feldt has written on his perspective of the project and our UX designer Magnus Burell had atalk on the UX side of things. And for the more technical side, our map-oriented developer Igor Tihonov will talk on this year’s FOSS4G in September.

Earlier post on Not even Wrong

Not Even Wrong – Reality Check IV: Guest Post: Creating a new map search experience

July 2014
Stockholm @ the office

My friend and colleague Daniel Feldt wrote a few words on one of our latest endeavors, and he was kind enough to let me post his text on these pages. You can read the original here.  

From my perspective, this quote is particularly heart warming:

“I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. …The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. “

Creating a new map search experience

In May of this year a small team at Hemnet launched a new full screen map search experience for 1.8 million weekly visitors at Hemnet.se. From start to finish we researched, designed, built and launched the new search in six months. The new full screen map search is, by far, the most fun and successful web project I’ve been a part of. This is a short summary of how we did it, from a user experience designer’s point of view.

I’ve worked on web projects since 1999 with everything from web hosting to light backend programming to interaction design and visual design. That’s 15 years of experience – quite a lot in Internet years. During these years I’ve worked in everything from huge corporations to the smallest of teams, and one sure thing is that the product development process has almost never looked the same.

Some of these projects were successful. Some weren’t. Some projects were never-ending, with a backlog managed by Mr Creosote and thus exploding to a gooey mess when the last piece of thin mint gets added to the backlog.

I would certainly categorize the Hemnet Map Project as a success. Successful launch and satisfied stakeholders – but here is something that’s even more important to me: a happy, inspired and creative team from start to finish. A team that leaves the project hungry for the next one.

Setting up the team

To wildy paraphrase, we were told:

“Bring home the full screen map search*, create a beloved fullscreen map search experience with new possibilities for added functionality for the user and future ad revenues. And do it as fast as you possibly can.”

* previous one was hosted and developed by an external partner

We got the trust to set up a small and self organizing cross functional team – running fairly autonomous with regular demos and and go aheads with management. The team consisted of:

• Two designers – With a range consisting of user experience, interaction design and visual design
• One researcher – A freelancer helping out with interviews, personas
• One business developer – Concepts, ads
• Two developers – Ruby, map tiles, front end

One of the developers were also team-lead – keeping the whole thing together and on track. Note that this were our titles and main focus areas. But all team members were involved from the get-go in everything in the project.

Everyone had a say during decision making discussions and because we had the trust from management and had all the necessary knowledge in the cross functional team – we could take decisions right then and there ourselves. Eliminating the time it would have taken to report, present and get go ahead from management.

We felt a true ownership of the project.

Decisions were made with a shared understanding for the value we would bring Hemnet and with regard for the overall goal for Hemnet. The trust of setting up this team and managing this project came with a couple of conditions.

We had to:

• Have regular demos that the whole company could attend where we presented what findings we’d done (early in the process) or what we were done building in the project.
• Break down deliverables to smallest possible chunks and deliver them to the live site to reduce future surprises
• Have regular retrospectives where we talked about the projects progress, if we were happy, what would make us happier, et cetera.

The discovery phase or “to boldly go where no man has gone before”

With all this we moved into a discovery phase. Again, all team members were involved in every aspect of this. During a eight week period we defined goals and metrics for the projects. The success criterias were defined by the team, not the management.

We researched, found and verified insights thru surveys targeting our existing map search users to track their needs and behaviour, sifting thru behavioural data from site usage and phone interviews with users.

We co-wrote user scenarios and project specific personas. We visualized concepts together, gathered feedback and built simple prototypes.

In the end we had lots of findings, prototypes and good stuff to work with.

Implementation phase

At the end of the discovery phase we had a pretty good idea about what we needed to build and how to build it. The implementation phase started with a lot of planning. Splitting scenarios into buildable chunks that we could deliver to the live site whenever they were done. That reduced the number of late surprises compared to pushing a huge chunk of code to the live site.

Again we did a lot of things together. Sketching concepts and drawing responsive patterns on whiteboards and paper – quickly presenting our ideas, throwing them away, presenting new ones and honing the good ones. Everyone sat together in a room covered with whiteboards, and everyone drew. This is by far the quickest way to iterate design solutions instead of a single poor designer detailing a wireframe and risk spending too much time on a solution between design critiques.

I’ve seen, been a part of and also been the culprit in projects where the time between design critiques grew longer and longer. And if a single designer spends too much alone time on a solution you can almost hear the Deliverance-banjo playing in the background. That’s never a good thing.

We met the challenges of continuous feedback in several ways. We had bi-weekly demos that the whole company could attend, where we demonstrate what we were building.

Once every week, always the same day and time, we also invited whoever wanted to come to a “designfika”. If you are a Swede, or ever been involved with a Swede, you are aware of what a “fika” is. It’s generally an excuse to have a cup of coffee and eat buns. At the “designfika” we gathered in a room with coffee and pastries and the design team presented whatever they were working on at the moment. The purpose was to gather feedback.

In a way we are all designers. Designers solve problems and that’s something everyone can be a part of. The people with the title “designers” have the task of presenting what the problem is, how the design solves that problem and gather feedback on the design. But, I guess my view of the role of a designer and the importance of design critique is another blog post to be written…

The last part of the continuous feedback is one the most crucial. User testing. We employed several ways of user testing and as always: the more user testing you can do the better. We invited users to our office and did 10+ interviews and let them try out the project. Quite straight forward. Now we don’t always have the time and resources to do something like this, and you probably don’t either.

Quick tip: The easiest way to quickly get input is to test on people from other departments within the company – which we did. My colleague Magnus also put together a homework assignment for everyone at the company with a single page crash course in user testing with ready made questions so that everyone could test the product on a friend or a family member.

All this gave us valuable insight regarding how the product worked, and this is something you could easily do whenever you are designing something. Not only will you get valuable feedback on the product, but you will also spread the knowledge of user testing to other parts of the company. And I can assure you that the majority of your colleagues will have fun doing it and they will also (hopefully) feel involved and invested in the project.

The importance of A/B testing or “Scotty, what do you think, forward thrust?”

After nine two weeks iterations with continuous design iterations and lots of backend development we finally had a product to start A/B-testing. This was important for us because we wanted to make sure that the tech behind the new map search would hold up for traffic and how the flow of traffic would change and/or disrupt existing ad revenues.

With a product ready for A/B-testing we started to deliver the new map search experience to 5% of our traffic. We had launched the project. Now we started the process of analyzing the stats and gather feedback from the 5% of users using the new map search. We got our hands on a handful of browser bugs and some map tiles performance issues and spent the last couple of weeks polishing the product.

Throttle up or “Scotty, we are going to need everything she’s got!”

Now, there are something quite fulfilling with having a big bang release. Push that button and release this new product to a surprised group of users. Shiny, new and scary (if you ask the user).

But starting out with the A/B-test meant that release day practically meant throttling up from 5% to 100%. Maybe not as exciting as a big bang release, but way better for your nerves and it makes it possible for the team to enjoy a beer at the launch party.

Post release phase or “The final frontier”

Just because we launched the new maps didn’t mean we were done. There were still stuff left on our wish list that needed to be done. The live site were running our most viable product with some additions. But still a lot of stuff to do – UX goodies, performance enhancements and such. The backend team needed to spread the knowledge of map tiles and all the work they had done to the rest of the developers and the design team had style guides to update and communicate.

Our keys to success or “how to keep the redshirts casualties to a minimum”

To quickly summarize our keys to success and how we avoided “redshirt casualties”. We had easy access to everyone we needed to talk to, we got insights from users from our user panels and behavioral data from Google Analytics. We had all the necessary competencies in the team to solve the task, and we were the decision makers.

We were “hands off” from management and were able to focus on our task. We had time to plan, learn, fail and then learn some more. Designers programmed and developers were involved in research and design.

And we communicated. A lot. Everything in this post is about communication. Daily stand up meetings, spontaneous and planned design critiques and regularly retrospectives that gave us concrete actions to improve the project and keep us as happy as possible.

Built by five people in six months. We are extremely proud of the result. You can try out the new map search here or see a little bit more of what I did here.

My colleague Magnus Burell held a presentation called “UX at Hemnet” at the UX All Stars (Yes, he really is an all star) meetup – check out his slides on Slideshare.

Our resident guru Thomas Lindqvist recently wrote about the final “super-retrospect” we had with the map search project revealing the questions and answers the team came up with. I wrote that communication were the key for our success – Thomas is the reason we communicated well and continued to do so during the project.

If you are remotely intrerested in product development process you reallty should check out his series of blog posts on that subject.

And I am sorry for the poor Star Trek references.

Earlier posts on “Not Even Wrong”