DX sets a new standard for product development tools

DX stands for Designer-Developer Experience— an experience that breaks the silos apart, reinforces knowledge transfer, improves performance and quality of the software we build together.

The future of design is engineering

There, I said it, and yes, I’m a designer. Why am I turning on my crowd, you ask? Here’s what we need to agree on before we start:

1. Design is how things work
2. Design should be driven by testing and data
3. Design is a process of continuous improvement

Now, if you crave spending hours pushing points in Sketch or Illustrator don’t even waste your time reading this. The design mindset I’m talking about reaches way further than a creation of a flat and static JPG layout or a fake InVision prototype.

If you are curious about how you can extend your lateral skills as a designer, developer or product director, read on, I will demonstrate how you can benefit from using DX mindset and why it’s worth to start right now.

Design as you build

In the early days, the available design software was focused on digitalising the creative process enabling artists to switch from paint and canvas to computers. Skeuomorphism was the best way to close the gap between the real world and the digital one.

At that time the development process was very basic, with many, time-consuming stages and no automation. It was changing fast tho, to the point when continuous deployment and testing are the status quo of how we build modern applications today.

As a designer with over fifteen years of experience, I look at Illustrator or Sketch workflows and see almost no change from when I was starting. Yes, they are more powerful and offer more features, but all of them extend artistic expressions and apply to an artboard not to interactive and sophisticated interface made of highly optimized components.

Adobe Illustrator 30 years ago and now

None of the creative tools tailor for the collaborative aspect of building software, nor they let designers test the real outcomes. You can try Figma, a collaborative Illustrator in the browser, but it’s not specifically ideal for interface design. Not at the scalable level and fitting our needs as professionals who must produce a lot of top quality deliverables.

So here’s the first claim or a takeaway from what we’ve learnt so far.

I’m saying “we” because none of this would be possible without constant discussions with my dear friend Dario Javier Cravero, a brilliant dev mind who took the time to educate me on the most important aspect of design — the technology.

A design is different than art. A software is not a painting.

A creative process of designing screens and flows for applications is a collaborative effort, not an individual quest.

Data as a result of continuous testing drives the best decisions not opinionated guesses.

If you could imagine an environment tailored for the above, what would it be? In what ways should it resemble the current tools? Should we wait for Adobe and Apple to create it for us, or should we build it ourselves?

Here’s how we describe elements of this new experience for designers, developers, and product directors to finally be able and build applications truly together.

We need:

1. One environment to:

• Break the silos
• Collaborate and solve problems
• Learn from each other
• Create culture of asking questions
• …suggest yours in comments…

2. A common abstraction layer to:

• Enhance the communication
• Unify the terminology
• Simplify and speed up learning
• Design as we develop
• …suggest yours in comments…

3. Nonproprietary output to:

• Integrate with any workflow, process, and environment
• Allow for flexible jump-in and jump-out points
• Morph the same build across many platforms
• …suggest yours in comments…

OK, this is how we see it, but if it would be up to you, how would you close the gap between tools we know and use today and the list above? What should be the base of it all? Should we make a bunch of plug-ins following InVsion Craft route or build something from scratch, an environment specifically done to fulfill this brief?

Continuous Design

There is a fascinating and compelling pattern used in development today. And yes, want we learn from it as designers and product directors?

Here how it goes. Each member of a team works on an element, a branch, a small piece of code to either improve its performance and quality or to extend its functionality.

If new code passes testing successfully it’s committed, merged and finally added back to the main repository, called master.

The interesting bit starts when the test is a failure. An engineer keeps changing the code and testing it, over and over again, until it works.

No one engineer masterminds, architects and develops everything by him/herself. Everyone owns the final implementation by bit. Everyone contributes piece by piece, line by line to make the whole app work. It’s a collective effort.

On the other hand, the design process looks usually like the Don Chichote’s quest. Full of crazy ideas and biased opinions constrained by the tools and culture of artistic expressionism. It’s me and my Illustrator, or Sketch, or InVision mockup until I share it with the team, only then to get another bunch of opinionated pointers, like why this blue is better than the other one.

There is usually no time for testing or what we test is a dumb click though that looks nothing like our final vision of the product.

The design is also disjoined from development. We hand flat layouts off and fake prototypes with no ability to continuously improve our work. We don’t run A/B tests as we build the product. We run them at the beginning, if at all, and in separation from the real app. In the end, since we don’t have access to and control over development environment, we have tiny impact on the state of the product.

So, here’s the second takeaway. An important insight into the success of the engineering process:

Build. Test. Repeat until it works. Ship. Gather feedback. Learn. Improve. Test. Repeat.

Can you do that in Illustrator or Sketch? How long until your InVision mockup includes only a part of the final functionality and interactions?
Is there a way for design to become embedded into product development as a continuous process?

Good [interaction] design is invisible

Functional, minimalistic and straightforward. Apps guided by these three rules end up to be the most popular and win the top charts despite the fashion trends or point in time. The reason why it’s hard to make that kind of apps is (or rather, hides) in the interactions layer.

Currently, it’s impossible to design an interactive experience, like the one showcased here, from the Uber mobile app, in any creative tool. Why is it so? Well, none of graphic design tools support the complexity of interactions and always changing implementation methods.

Yes, you can use FramesJS to fake some of these flashy animations, but even with Sketch files import you need to learn Javascript and Framer’s syntax from the vast and complicated documentation.

At the end, what you get is an interactive prototype usually focused on one interaction or part of the flow. Reality kicks in again in which the detached designer works for days on a prototype that won’t become a part of the final implementation. And that is such a waste.

Our takeaway:

Don’t waste any pixels. Design as you build. Take control of the final interactions layer to make the most functional, minimalistic and intuitive apps possible.

DX/DC

Today we describe DX as an experience. It plays its role to start the conversation on breaking the walls between teams, bringing the silos down and speeding up the development process. Here are couple of simple rules we follow to induce DX mindset in the organization:

Do’s

1. Ask questions
2. Always answer, explain, help and guide others
3. Think of yourself as a mentor
4. Make friends and have fun

Dont’s

1. Wait too long before answering someone’s question
2. Assume others know what you know
3. Be too strict to others who are looking for help or give them too hard problems to solve
4. Be an opinionated, judgmental, close-minded expert

In the long-term DX converts into the culture. It’s no longer set of DOS and DONTS. What kind of impact does it make? Here’s what we’ve noticed:

• DX defines the way we collaborate with others.
• DX expands our ability to learn new skills.
• DX shapes the way we respect each other decisions.
• DX improves the quality of what we build.
• DX influences our habits and mindset (it’s not a process).

Is DX for me?

As an individual and a professional ask yourself these questions:

1. Do I want to learn how things work?
2. Do I want to be seen as a team player who is not afraid of asking questions?
3. Is my long-term goal to achieve a leadership position in my career?

Is DX for my team?

As a part of a team, department, company ask someone close to you, a teammate over lunch, a manager you trust, a colleague from another team, these questions (because of private nature they work well in one-to-one conversations, not always on a team meeting):

1. Are we ready to help each other on our team?
2. Do we create a trustworthy and safe culture for others to feel comfortable enough to ask questions?
3. Is it acceptable for your team to experiment and innovate with tools and processes?

If you answered — Yes — to all of the questions above, you are ready for DX, and you can try to implement your DX tools or sign up for our early beta release (out in January 2017), called ViewsDX.

If you answered — No — at least once, DX might be not for you. Don’t miss out, though, get in touch with us and our Slack community to see if we can help you make it happen.

Maybe you just have some questions? Again, don’t be a stranger. We love what we do, and we will be delighted to help you out in any way we can.