Parallel reality in design

In parallel reality design, various design artefacts such as wireframes, mockups and prototypes does not reflect final product experience either in form, function or both.

I consider this phenomenon to be one of the main reasons for not-so-successful design execution within large enterprises. Recalling my own past experiences helps me to see whether I am on track with current design approach. When I spot any parallel reality symptom, it is always sign for me to pause for a moment and reflect on design process itself.

Vision Prototype

It starts with the best intentions. Lets design UI prototype as unconstrained vision. We have proper user research available and this is how we want to address people's goals in next 3 years. At some point, we will include all the detailed constrains — technological challenges, engineering capacity, internal politics and business goals.

While there are situations where vision mockup can get initial buy-in and help to shake things, in most of the cases this ends up being castle in the air.

Out of all industrial design disciplines, this is symptom specific to digital product design. People tend to believe that picture of the product is the actual thing, and they commit to something that is just not real.

Even in highly technological companies, this is not about stakeholders not being able to see associated technological challenges. It is more about imagining, that as you are driving the car and having fun, someone is telling you that the car actually does not exist. But you just drove it, right? Stakeholders tend to believe that someone just figured it out, but in reality someone just draw sketchy picture of it.

You don't need abstract thinking to imagine how far is initial picture of car from actual driving experience. It is very challenging for humans to apply same senses in digital space to something that they can experience almost in its final form.

So we just assign engineering team, figure out the engine specs and and plan release date.

Parallel Reality

Creating prototype of advanced product that 3 times larger team cannot build in next 3 years is not product vision or unconstrained design. It is picture of a car — a parallel reality mockup.

Even with staged development plan, when looking back at original vision prototype and shipped product increment, these ends up being different products, addressing different goals.

When I spot this symptom and catch myself designing User Interface that I have no idea how and when will be shipped as fully working product, I try to get clear internal commitment and see through corporate politics — what is the real motivation behind the design artefact. Is the intention to move ideas through internal pipeline, send market message or really ship this thing?

It will come later

All the teams I was part of were led by engineers. In large IT enterprises, product management as key source of domain knowledge is often formed from highly technical former engineers. Engineers have amazing skills of abstracting problems — they are "object oriented".

Imagine that there are objects called Make Sound and Chase the tail. After these are assembled, few more objects with strange body-parts names such as Head, Fur or Elbow will come through the pipeline. If you are non-engineer, you might not see that I just described living and barking dog, without any need to call it that way or define this object in advance.

Now image talking to someone who can see the dog and trying to convince him that he can not build the product without knowing exact navigation structure, grid system, responsive design strategy, data visualisation or even visual style. Off course he can — he will add it later.

For engineers, User Interface is properties and methods.

Designers have to use certain level of abstraction to be able to execute design within agile environments. Attempting to execute all design before engineering starts leads to "Vision prototype" parallel reality.

But it is extremely important to define what UI elements have to be defined in advance, because they simply defines the product. And if they are not defined, they can not be added later, since then the team is just building different product.

This is often point of "object oriented" thinking clash. Engineers tend to believe that once they work on correct application logic, getting correct data and present them 1:1 in UI, designer can figure out the right visualisation later and arrange the stuff in better way.

But then later outcome of user research is that there is no need to visualise these correct data at all. To fulfil users goal it is just enough to know whether they exist or no, people don't care about the content. Good luck explaining to engineering organisation that next iteration improvement "coming later" means that they should remove all the interaction they were building over past month and replace it by simple text summary.

When certain parts of design process are missing but engineering factory is already rolling, it is almost never reason to postpone or cancel projects. If there is research missing — it can be validated later. When detailed UI specs are missing and product is developed according rough sketches — it is visual skin that can be redefined later.

It has correct features but looks a bit chaotic. But we will address that later, it is just the skin.

Parallel Reality

In real world "adding later" moment will often never come and has nothing to do with being agile. Enterprise products stays in their rough initial form 1:1 representing underlying data and abstract object models. It is simply not possible to consider User Interface as abstract object like any other "object" in object oriented programming. User interface is the product. If it does not exist, the product does not exist - it becomes to be parallel reality.

It is always alert for me when I hear "it will come later". Even under time pressure, I am always trying to get through the whole design process — from user research, sketching, prototype, visual design and final specs. Even that for each phase I might deliver imperfect outputs, I can recognise key UI elements early. I can commit that what was bar chart in sketch phase will not become 4 grid dashboard after detailed "visual skin design" and user validation. I am trying decrease abstract thinking and make design tangible and taken seriously. If it is not designed, it can not be coded first and tweaked later.

Conclusions

I believe that to some degree these symptoms exists in every project execution. It is essential for design to be one step ahead before engineering. And with this extra step, there is always risk that design artefacts might get disconnected from actual implementation reality. However through cooperation between product, engineering and design standpoints it is possible to ship well designed products and include all needed compromises. Even that it might sound obvious, these three streams has to be executed in parallel to achieve tight relation.

Liked it? Please recommend it, or continue reading with Enterprise UX publication.