PSPDFKit GmbH, at its heart, is an engineering company, and engineering excellence is always the highest priority. Building a framework that thousands of large and small teams use is no trivial task in the first place, especially when our goal has always been to provide the best experience to our users. It’s no surprise that the engineering teams make up about 80% of our workforce. Thus, I’d like to share my experience as a designer working in a flat organizational structure with teams of engineers, and how we approach design tasks when there are no defined hard lines that segregate responsibilities between individuals.
As our products are highly technical, it would be easy to assume that engineering trumps visual and experience design. Just as, for designers, it’s easy to suppose that everything needs to look perfect. The reality is that engineering and design are both essential aspects when creating a product, and understanding the significance of both makes team discussions and collaboration much easier.
We’re lucky that our company culture promotes a strong sense of equality. Every team member’s contribution is important in making a product great, and no one’s effort should be overlooked. I find it effective that our weekly meetings include insights and demonstrations from all team members, as it helps establish a thorough understanding of what’s happening across teams. The culture also empowers us to ask questions and join discussions, so no team is sealed in a vacuum. With open communication, every team is aware of immediate and upcoming needs between projects, including anything related to design.
This all provides healthy doses of respect between teams and team members, and in turn adds weight to people’s input and opinions, as their competence is better understood. With that in mind, it’ll be easier to accept the following facts about the role of design in an agile team.
Every developer, tester, support technician, designer, and users are all part of the design process and heavily influence the design of an application, be it functionality, user experience or visual appearance.
This is something that can often lead to pushback from a designer, because of the feeling of their turf being intruded on. Especially if a designer comes from a less agile environment with rigid structures and strict responsibilities. Fuzzy lines between who does what can be irritating. One is easily led to believe that certain types of work are always a specific team member’s job or responsibility and others aren’t—it’s hard to hold this attitude in small and agile teams.
Case in point: That’s a mockup created by David, the team lead of our PDF Viewer for Android. To be completely honest, any style improvements that could be made here would happen during the implementation phase, while we’re iterating the view, anyway.
It’s tempting to think that things need to be done “the right way” in terms of process and structure, and that orienting yourself on other—often much bigger—companies workflows would make your work better and easier. But that really depends on the team size and the jobs to be done. Such structuring and managing of workflow might only give you a false sense of accomplishment that isn’t really productive. Agile approaches for work enhance quick turnaround times and results. While strategizing about the “how” may give you a sense of security, in small teams, ineffective communication can take up a lot of time that could have been spent on the product.
In my experience, I’ve noticed when a person came from a more rigid organization, like an ad agency, or even freelancing, he or she would need some adjustment and it’s important that the process is actively encouraged in order for one to have an easier time readjusting to a more agile approach to work. Without encouragement, even someone who wants to do good work might feel anxious and have a hard time proactively seeking out tasks or deciding what to work on.
One thing I found helpful during my transition to a more agile approach is to switch the mindset from “Deliver the deliverables” to “Make the product better”; it might sound like a small change, but it helps with understanding the environment that an agile team operates in.
It’s a constant juggle to pick tasks, keep everyone up-to-date, and take on more responsibility, self-management is a great skillset to help you get there. It does take some time to adjust to the new pace, yet one usually ends up feeling greatly rewarded accomplished.
Circling back to the point that everybody designs, the biggest reason that interface, visual and web design work smoothly at PSPDFKit is that there’s explicit trust in people, trusting that we know what we’re doing. For example, when a developer works on an app, or framework, and knows what he should do, the whole loop of initial wireframes, screen transition mockups, etc. can be skipped (for the most part).
For us, the benefit of trust—in addition to mutual respects between team members—is that work gets done faster and everyone is more engaged when developing products. So when the time comes to get the designer in on the discussion, a number of problems have been solved already and even those that haven’t been are much better understood than they would be if wireframes were on a piece of paper only.
To demonstrate the upside of trust, Matej implemented the view above for our framework. My involvement was simply suggesting that we could make the red color a bit darker. Because Everybody Designs, he didn’t have to wait for me, and I didn’t have to draw up view elements that needed to be done in code, anyway.
Quick iterations don’t apply to every scenarios—just as with software development, there are phases when more time, a bigger team, or longer discussions are necessary to develop a project. This can be frustrating, especially when one is used to getting quick results, but can be likened to refactoring an app’s core component or cleaning up a framework API between big project version jumps. As an example, when launching a new product you really want to make a good first impression. Just pushing out “something” with the intention to iterate over time will end up hurting you, especially if you fail to market your product well.
All in all, however, having a flat organizational structure that allows every team member to access a designer directly has streamlined our workflow a lot and allows everyone to work more efficiently. We’re still working out kinks in the process here and there, but so far we’re achieving a good balance of output, quick iteration and a fair share of responsibilities.
In summary, I find it useful to share our approach because it’s likely that many young companies find themselves in similar situations when they don’t have huge sums of VC money being thrown at them. Here are my takeaways:
Trust your team and their ability to take over tasks outside of the job descriptions
Skip complicated workflows when only a few team members are involved
Learn and use the tools that the majority of your team use to reduce friction
Encourage interactions between team members across all teams
Agile approach is not an ultimate solution to all projects and you should re-evaluate its use between project phases
You can read more about some of the tools and practices we use for design tasks in the next article!