Setting up design-driven culture

As a science graduate, I’m always impressed by the beauty of nature…

Getting Started

In this article, I’ll cover the transition from requirement to design driven culture. Since the early 2000s, software companies wanted to deliver exact requirements for their customers. Even if they realized that customers actually don’t know what they need, they followed this method for years, and challenged both sides. Through years, they also realized that design is getting important to attract customers. So they started to use wireframing tools to understand the customer. In the beginnings of my career, I also saw wireframes in MS Visio and Balsamiq. They are generally black and white, and mainly focusing on user journey. It was also possible to have a primitive prototype. In 2018, a friend mentioned me Figma for the first time. I still remember the first day when I created my account on Figma. It’s just a blank page. I was searching components like in wireframing tools. When I couldn’t find anything, I started to search on Google: where are components on Figma? The result is inspiring, you can create one, draw a shape, paint it, adjust radius, add a text, voilà. Now you have a button! That’s how I met with Figma, and still love it!

Product Designer

According to the Collins English dictionary, product designer is

• A person who designs the appearance, functionality, and user experience of products, typically working in fields such as industrial design or consumer goods.

First, wherever you are, you will need this person in your organisation. This person is specialized in this field, and ready to create miracles if correctly paired. If you don’t have one, hire one. In my case, my first product designer colleague was Banu. She is open-minded, and ready to dive in challenges. You’ll also need someone who understands product development. If you don’t have, hire one. In our case, we did an excellent job together.

Data gathering

Initially, both product designer and product person starts working together, and gather as much data as possible. We preferred having screenshots, and comments on Figma. The chaotic view on Figma with screenshots, and comments slowly faded out when we processed them. This helped us to see how competitors offer similar functionalities, and we were able to assess them. Ideally, you will have enough data to start after a few days. Because most of the beauty today in software development is lost during translations from one ear to another, and we easily leave comments on gathered data, add notes.

In traditional companies, the product designer is running waterfall style (research, ideate, wireframe, user testing, high fidelity prototyping, coding). We didn’t follow it, but adjusted a little bit. Even if companies try to adapt agile principles for their development team, somehow they still follow waterfall principles in their design processes. Worse, they see that it doesn’t help the company to build the best product in the world, they still rely on it.

User Journeys

After a few days of data gathering for our business domain, we already have enough data, then we start processing them to see how puzzle looks like in the big picture by placing pieces of corners. Based on this picture, we dream a user journey. If user journey is blurry at some point, we go back to data gathering, and collect a bit more data. We start creating production class prototypes on Figma, not wireframe. Later, Banu told me wireframing could be helpful during initial exploration. To be honest, it took time to prepare UI components, and design guideline when we do it together, but after a few days, we were faster. Because when you already have UI components, using shapes in black and white slow down the process, and using UI components speed up our process. Whenever we have something we like, we go to stakeholders together, and get their feedback after little to no information. Expect your stakeholders to understand what’s happening. Based on feedback, we repeat this process until everyone has fully clear understanding. Sometimes we are so fast, then Banu asks time to process them, and think clearly what could be the best design pattern, and later, we sync, and continue again. Sometimes I’m slow, and ask time to clarify business domain. Then sync, and continue again.

When designing user journeys, here are the key factors you must keep in mind

• Persona: The person who is going to perform an action.
• Goal: The person who is going to accomplish a goal or task.
• Channel: The person is going to have a seamless experience on a device, possibly mobile or web or mobile optimised responsive web app.
• Onboarding: User should understand how to interact with the app without hassle.
• Clear path: If you want user to add an input in a field, don’t tell later you made a mistake some time ago somewhere. Talk to user in real time, and tell what’s happening.
• Minimize Interaction: User doesn’t need everything, show them only what’s relevant, and give an opportunity to access more.
• Error Handling: User should understand when they complete an action by receiving a clear feedback. Make error messages informative, actionable. Something went wrong is not a helpful message.
• Integration and Consistency: User should have similar reactions, interactions through all over the UI. That’s how people learn using a software. If there are inconsistent UI patterns, it’s going to confuse users.
• Testing and Iteration: Keep refining user journeys with every simple user action.

Your product designer is generally good at above details, but it’s good to be aligned, and show that you have same understanding.

In traditional companies, testing and iteration are slower, more bureaucratic. Dynamic companies know how to communicate in sync and async.

The Problem

The problem in our industry is to relate every single idea to a problem. Everyone is thinking about solving a problem like a machine. Give me a problem, and I will solve it. I explained in another article why problem-solving is misunderstood. We don’t need to solve every single problem. Because maybe the problem doesn’t worth to solve. If you don’t see the big picture, and deal with small details, then you might be lost there, and you start giving priority to the wrong pieces. You will think that problem is solved, but holistic view is missing, problem is actually patched, still partially makes sense. Therefore, gather data, and see the big picture first. Only continue if it's worth to solve a puzzle. Most likely, your first and last ideation will be different in a complex business environment. First one is generally very classic visualization, but the last one with some wow affects especially in the highly engaging parts of the product.

Product Requirements Document

It’s another tradition in software companies. Sometimes I’m feeling lucky that computer systems are developed within the last 40 years, not before. Imagine how companies try to work a few centuries ago, scary. Even today, there are some companies rely on documented workflows.

• What if you write it wrong?
• What if you write it correct, but it’s misunderstood?
• What if you didn’t write?
• What if you write it correct, and it’s meaningless?

I don’t mean that documents are waste of time. Documented workflows are bad. When someone thinks about something else, and write down whatever understood, this might be wrong, partially correct, but never fully correct. It’s difficult to write a comprehensive requirement document. I have never seen anyone successfully done it. What you ask, and what’s delivered always different. Once I tried to do it, I had to find out related parts, and update every time whenever I get a feedback. It’s useless, plus, exhausting.

When the feedback loop is longer, you are close to die. There is no way to win a competition in the market if you like writing documents, and work in bureaucratic ways. If you don’t have any interest in competition, and think 2% market share is good enough to survive, and retirement, it’s also a choice. But you need to find like minded people, because others will leave the organisation.

Design-Driven Culture

Design driven companies bring empathy to the organisation. Empathy helps us to better understand the customer, provide better experiences. Therefore, product designer should be the core part of any software company today. But relying on traditional workflows won’t help you to achieve great results. Be open to new processes, if you are not, how do you know your current process is good? Probably you don’t have data, you just rely on someone else’s words on a book or a medium article.

In the past, we were able to work async, because tools didn’t allow us to work together in real-time. Today, design tool Figma gives you an opportunity to work together in real time, but people still rely on their past experiences, and don’t want to work together. I don’t mean that always work in sync mode. But it’s super helpful to think, visualize, and criticise together. Customers today want to have experiences that fully matches their needs, or even better.

Beside that, there will be some conflicts of ideas during ideation with stakeholders. To avoid hurting each other, and open a chance to grow up, empower your product designer to make the final decision. If someone arrogantly thinks, s/he can do it better, change the roles, close the discussion. Life is too short for an eristic dialect. Later, I’ll explain Circle of Competence and some mental models in another post. You can use these mental models to drive success, and better investment management.

Missing Piece

We managed to change the culture from requirement to design so far with this progress at Defne. Software development without a development team is currently utopia, we need developers. Meanwhile, I’m researching a way to minimise the need for developers. Recent developments in AI can make it possible. If you set up a virtual barrier between your designer and developers, it might be also too late to technically evaluate options. Technically, everything is possible, but has a cost. We often have to make decisions based on cost, and return of investment. But this is another story.

How do your product designers hand over their design to developers? Most likely with a message or a session, here is the JIRA ticket, here is the link to design, and prototype. This is another traditional workflow, good people do it like this, but really good people not.

I also fell in this trap after working with a product designer for a month. We had prepared so many user journeys, interactions, and the platform is ready to be developed. But we didn’t ask any engineer to have a look at what we are doing. Later, when we wanted to hand over, it took their 2–3 weeks to translate screens into their development world. It was a bottleneck in the development pipeline. Then I started to think how we can solve this issue, and development team can spend less time to understand what’s happening on each screen. It took a year to find out the solution.

At the end of 2021, I moved to Germany, and started to work in a DevOps company where I met a really good guy. I had some background knowledge about databases, and schema design, but I never did it by myself. I learned how to do the conceptual models here, their logical relationships, and finally physical modelling. Not the best, because it’s not the job of product people. Basic knowledge is good enough to get started. One day, my colleague Jakob brought an idea to the table, OOUX (Object Oriented UX). I had no idea, so we started to work on it together. OOUX is developed by Sophia Prater, who figured out how software developers work, and changed the way she works as a designer, and it’s known as OOUX today.

What does OOUX mean? It means people are thinking in terms of objects. For example,

• I have an apple.
• You have a watch.

And then, people take actions on objects. For example,

• I bought an apple.
• You sold a watch.

This is how developers work, they call it object-oriented programming. Imagine, you want to sell a car on a website. Object is car, let’s define it simply.

Car

• has 4 wheels,
• has 4 doors,
• has air conditioner,
• color
• transmission (auto or manual) etc.

What people do on this object, car?

• Buy a car,
• Sell a car,
• Find a car etc.

OOUX is not just about defining objects, and actions. Because I started to do it in the conceptual data modelling. OOUX also helps you to rank which actions are highly important for the end user. So you start ordering actions by their importance from top to the end. Think in terms of e-commerce, you have a product page, where people can see product details. Which action should have the highest importance?

• Buy it,
• See more about product details,
• Add to the list,
• Add to the basket,
• Download product manual,

How would you order these actions on the page? Actions have contextual validity, depends on your business. Primary purpose of your business in e-commerce is to make money by selling products when a user lands in product page. So first action should be “Buy it”, and so on. Here you can learn more about OOUX.

Next time, when you apply OOUX principles, you will see that your product designers are easily explaining their conceptual work to the development team, and developers just verify, and optimise the conceptual work. So they won’t spend their time to find out the complete view from 10 different user stories, 20 different screens, 30 different actions.

Unfortunately, my experiences are over here, and this is how I solved the puzzle between #product #design #engineering disciplines. Always stay open-minded, and drive the changes before changes drive you. Read my old post here to find out what I mean about changes, and happy to hear your stories.