Zoe's Blog

I've learnt a lot in past couple months about design and oh boy, it's so much harder than what I first imagined it to be.

For us, when tasked with adding some new functionality, we used to sketch out some low-fidelity wireframes and then get straight to implementation, providing a very quick route to delivery. We have no design team, so it's up to the developer how components look and interact with the rest of the page. At that point we'd test it amongst the team to see how it felt and then made improvements from there.

It's not a bad way of doing things, as in a small team of four to six developers (with a varying degree of how much they leaned towards the frontend or backend), you can still easily communicate and talk about what you're implementing. But with this approach I found that we ended up patch working together a lot of our UI components.

We had no basic re-usable building blocks, as most became context-specific, since they were created as we needed them for particular pieces of functionality. This meant that whenever we had a new chunk of functionality to implement, we would often have to write new building-block components, most likely very similar to existing ones. As a result we ended up with an inconsistent look to our pages, as well as bloat to our codebase, with pieces of functionality squished into existing ones as we incrementally increased what a certain component could do.

Here's a summary of the advantages to this approach:

Quickest path to first draft. This approach let us get to the simplest working version of a component or page as quickly as possible. With the ability to show the component and get feedback, we could iterate quite quickly on the component itself.
You don't need extra manpower. We're a small start up-- we don't have a trained designer on the team. Being able to roll up your selves and do it your self means you can design with the knowledge of what is technically possible in mind.

Of course, there are trade-offs...

It's easy to lose track of the bigger picture. This approach often lead us to ignore considering the app as a whole. If I add this component styled like this, how will it effect the app? We can style it so it looks somewhat similar, but there is nothing enforcing it to be so.
You miss out on all the benefits of having a trained designer. We didn't have a designer to consult on how to best layout or even colour components for visibility and showcasing functionality in the best possible way. As developers, or for me personally before I started learning more about design, were more focused on achieving functionality, even though it may not be the best possible route for the user, nor may it be the prettiest.

In a previous (and larger) company, I was mostly working on the frontend as a developer, so still had a lot of interaction with designers, but was used as more of a sounding board for choosing between options that they had come up with. My role was feeding back to them whether it was technically doable and my general thoughts as a set of fresh eyes. But I found this approach to be quite slow.

We had a bottleneck, as a team of developers vs a team of designers. We often found ourselves waiting for the design team to finalize their designs and this lead to more pressure for us as launch dates loomed ever closer.

To be fair, in this kind of set up it's totally right that they needed to take their time doing it, as they had not only the initial designs but user testing to do, in order to be confident enough to give it to us to implement. Design is a process and it takes time, but what I would have liked is a blending between the two teams. Why can't developers be a major factor in the design process? I would have liked to see us doing more than the once-or-twice-a-week meetings with them.

And we did push to work together more, but this often came closer to the deadline than was comfortable. I believe this was due to them having to juggle other projects as well as ours, as well as the pressure on them to get sign off on designs before officially handing them to us. Because of their time constraints, they could only really spare time to sit down a handful of times with us so we could pixel push any components that didn't look quite right.

This did work well for us, in that it meant a designer could ensure that the page looked as they designed. I really enjoyed working directly with them and so think we could have benefitted from designers actually in our team. But big companies can have many different departments, so I can understand them wanting to lease out teams of designers on each one as needed. Still, I wonder how much quicker or better we could have produced interfaces if we were intermingled.

Advantages to this approach:

A team to enforce consistency. We had a whole team that concerned itself with the consistency of the look and feel that components and pages had. This meant that by the time we developers got the designs, we could easily see how we'd implement re-useable components in order to achieve it. We'd even get specs for colour and spacing. Lovely!
Proven before implementation: The design team perform user testing to prove their designs let intended users reach their goal easily. This means a higher chance of users finding the real thing easy to use.

And the disadvantages:

Technical limitations can be ignored. Sometimes designers can assume a behaviour is relatively simple to implement... when actually it's incredibly difficult and not worth the time or money. Having more developers in the room when they were putting the designs together could have nipped that in the bud and steered them down a more achievable path.
A longer time to release. This is just something to keep in mind. In the short term, this approach takes more time with the processes that the designers went through in order to achieve sign off, but you could argue that in the long term we save time. This is because the designers have ironed out any problems with interactive behaviour or user paths before implementation, saving possible iterations that the developer would have had to make to fix it. It also means the previous components made can be used in future designs, reducing the time to put together new components in the long run.

So I had seen what a relaxed design process looked like, as well as what a more rigorous, separated-from-developer design process. How can I get it just right?

Ideally, I wanted to be somewhere in the middle of the two approaches. We had the constraint of being all developers, so it was time I learnt some design skills. This is not easy, and I am still easily a novice, but I learnt enough to set up the following process, as well as the skills to run it. So this is our current design process:

From the given problem, derive the functional requirements This means that for a given problem, what are the ways that we can solve it? From those solutions, what must the app be able to do?
Create simple prototypes to test routes in the user's path This is to test the best path that a user should take between states, as well as planning out roughly how much information to show them at any one time. It should cover all possible states that the user could get themselves into and is normally done as low-fidelity wireframes. It helps if you get some feedback on these basic mock ups so that you know which to focus on in the next couple steps.
If you don't have them already, decide your colour palette and text types This is important for high fidelity wireframes. You'll want to be able to easily reference key colours and typography while putting together designs and will make your designs follow more of a theme.
Create a set of high-fidelity wireframes. Options are encouraged. This is where you can focus on the look and feel of your wireframes. Options for different ways to display information is encouraged.
Release the first draft on a tool that lets members of your team comment on them. By making the designs available to everyone in your team-- from your boss to the backend developers, to the business and sales guys, they can all give their input. You may be surprised to see just how useful this is at sparking discussions on everything from general wording and clarity, right through to how this is or is not achievable from the current state of the database.
Improve designs based on feedback until complete. A natural preference should occur. After iterating on the designs, you should start to feel like everyone is on the same page with you for these designs. Plus, if you use a collaboration tool like Invision, you even have a record of all the discussions on a design, so you can track how any why a particular design has evolved.
Achieve initial sign off Once everyone is happy enough with the designs, you can sign each wireframe off one by one.
Break down your components and map all states that they can take. You should know all of the main states that your components can take, now it's time to make sure they are all accounted for so that they can be implemented separately. We followed Atomic design for this (another first for us) and I have found it to be really useful in helping enforce a distinction between common, re-useable components and more complex components that are intended for a specific purpose.
Release your components on a Design System. This took me a while to organise, but has been really worth it since developers can pick up a ticket that references a component and go and look up exactly what it should look like in all it's states. It also helps other team mates that want to dabble in design, as they can drag and drop components into Sketch with the help of a plugin called Craft. Sketch + Craft + InVision makes the whole design and share flow very easy. InVision also has a Design System Manager that you can use.
Start implementation, hurrah! It's time to prioritise the components you have just designed so that the MVP for the solution can be reached. Inevitably, during the high-fidelity wireframing I tend to find I've added a load of 'nice to have' components. It's important as a development team to go through which components exactly you need done and by when.
Revisit as needed. In my experience, sometimes some designs don't feel as right when implemented, so be prepared to make slight adjustments to your designed components as the implementation is completed.