Recently I attended Generate Conference in London.
As a design and development based conference I also had our lead designer Eden along for the ride (Her experience can be found here). While there was a whole host of amazing speakers and great ideas shared at the event, as a developer, here were my biggest takeaways.
Ownership and understanding
One of the great points covered by Verne Ho during his talk “The Design Practice” was the need for ownership within a team.
It’s a problem in any team environment. I have experienced this issue throughout my studies at college and university, as well as in the real world. In some scenarios, one member of a team might give it their all, whereas the rest might not.
This then reflects badly on the team as a whole. Excuses being thrown around similar to “Oh, I’ve done my bit” and “This wasn’t within my remit” should be seen as a failure within the team. The issue often comes down to an employee’s ability to hold themselves responsible for the team’s results.
Often, we don’t make decisions or take ownership of work because we are not quite sure if we should. It’s an issue with how teams and roles are structured; we may feel like we need to check in with management or are afraid of making a decision without their blessing for fear of failure.
In this light, project teams can sometimes fail. One of the great takeaways from Verne Ho’s tips in this regard was visibility. A simple concept that struck a nerve with me, at Shopify, they enforce twice-weekly “show and tell” sessions, which they refer to as “fresheyes”.
Aptly named, they are mandatory sit-down and show and tell sessions, taking people away from their usual daily routines to present to their colleagues what they have been up to since the last catch-up. On small and large projects, when a catch-up might usually be once every other week because people just trust everyone to get on with their jobs and be on the same page, is a practice that we don’t follow..
Between teams, things can always get lost in translation, while long email chains explaining complex ideas don’t cut it. Getting a team together for 10 minutes to discuss a problem is better than three hours’ worth of back-and-forth emails.
It should instil passion within every member of the team on their project. Even if it’s not at a development stage, a developer can get excited by the design if the designer is passionate; likewise for strategy and content, SEO etc. This should be true all the way back to the origin of the idea, which the whole team should have been a part of.
We should all feed off each other’s creativity, knowledge and, above all, passion for work.
Allowing time in schedules for twice-weekly catch-ups with a project team ensures that passion remains with all members of the team and visibility for everyone is the same. While I don’t know how many inter-office problems this little bit of extra time to sit together and talk will save, I feel the results will speak for themselves.
Another talk we attended on the first day had aimed to give 40 tips for retrofitting responsive web design in 40 minutes. I couldn’t help but notice during the talk that all the advice offered basically covered what we do at Branded3. There was nothing touched upon that we either don’t currently practice or don’t have a solid plan in place to introduce.
Having come up with the UI architecture and planning process at Branded3 myself, despite being a lowly front-end developer who’s barely into adulthood, I felt a very powerful sense of vindication for having made the decision to move the company away from bootstrapping projects as well as other changes to our approach to front-end code. As a young front-end developer wholly aware of the wider world of programming he still has to learn and master, it was nice hearing that, for at least with my current expertise, I’ve been hitting the mark.
The advice offered was great, don’t get me wrong, and for many, those tips and expert solutions might have been new concepts or better ways of working. However, we at Branded3 can rest assured that, for now, we are at the cutting edge of best practices for responsive web design. As long as we keep our noses to the collective grindstone of all our practices, we will continue to be cutting-edge and push the boundaries of what has already been achieved.
The last talk of the first day featured a legend in the world of web development, Eric Meyer, who gave a riling talk focusing on “empathy”. I don’t think I spoke to a single person who wasn’t flabbergasted by the simple idea he put forward using a personal story of tragedy to outline obvious UX disasters.
The story was of a very ill child, a panicked parent and a badly-designed hospital site. He went on to describe the need for us when considering the “user” to factor in how someone will be using our products in various circumstances and that not everyone using our products is going to be our ideal “calm and considered” client.
Often, people might be using things we produce while short on time, or frustrated by life. In this regard, we need to ask ourselves about the personas of our users. Have we built our product will all scenarios in mind? Does it work for those calm and collected users as well as pressed-for-time and stressed people?
He offered some other real world examples of this type of consideration having been made. One of the more uplifting examples was again hospital-related; he highlighted the issue, in this case the number of children who needed to be sedated in order to keep them still inside an MRI machine, which was quite large – almost 100%. By redesigning the MRI from this…
…which doesn’t look very friendly, to this…
This astoundingly simple thought apparently resulted in a drastic drop in the number of children needing sedation, therefore resulting in a much higher patient capacity. In all, it’s a real world example of how well-considered design actually helps to save lives!
Consistency in responsive web development
The only talk that stood out to me as a developer from the second day was from Patty Toland. Her talk was a run-through of the history of tackling responsive web design as the landscape has changed. One of her key thoughts included people’s underlying assumptions.
“Devices are uniform and predictable”
This may have been true in the landscape of 2007 when viewing just one manufacturer of devices; her example focused on Apple.
IPad/IPhone portrait and landscape: 2007 – 2014
She then gave us a reality check; for anyone unfamiliar with the difficulties facing responsive web development, this should have being a sobering reminder.
Samsung touchscreen devices, 2014
Android mobile landscape, 2012
Android landscape, 2013
Android landscape, 2015
She also highlighted the importance of thinking about the new mediums coming that we will soon need to consider in the form of the Internet of Things. So, it’s clear we have a lot to think about particularly the difficulties inherited from the sheer number of screen sizes, browsers and operating systems we have to support. On top of those considerations, we also need to think about network latency and the performance of our products. So, the thought here goes on to encourage a change to how responsive design is practiced.
This is a consideration to be taken more by the Design and UX Team than by the developers; the technologies and tools that currently exist do the job. But, if a design hasn’t been well-considered for the ever-changing responsive landscape then, no matter how much work a developer puts in, something isn’t going to look right somewhere! There are only so many devices we can test on and a finite number of hours in a day. The argument for time spent over practical use isn’t black and white, as Patty herself said:
“No matter how prepared you think you are, it’s really hard to predict where traffic will come from. So, responsive web design needs to support a full spectrum of experiences, even ones that haven’t been invented yet.”
From this, she went on to explain the process at the Filament group and how they tackle this far-reaching and often vague specification. They have a system in place which they apply to projects to overcome a lot of the constraints that come with responsive web design. We have our own similar development practices; however, the big push I got in Patty’s talk was that a lot of the issues of responsive design need to be tackled in design rather than figured out during development, so much so in fact that she even went on to say:
“Make speed part of the design process, set performance goals in the design spec”
Some of the challenges suggested that could be faced by designers are things like image/video/audio inclusion, custom fonts and third-party tools. All of these things are never usually considered as detriments to fast page speed by the designers, usually due to a lack of understanding.
The designers of course can’t be blamed for this lack of understanding; it could be argued it isn’t their job to understand, that’s why the world has developers. But to have a fully symbiotic relationship in the business as Verne Ho suggested, bridging skillsets between teams improves the eventual output.
So onto the final revelation Patty gave me; this all comes down to testing.
Two things stood out to me and they are things I’ve been thinking for some time. When it comes to testing, there is a resounding apathy in the Development Team. None of us enjoy it, but I’m sure this isn’t an isolated case – the world over, I have no doubt that developers detest the dreaded “testing” phase. Not for difficulty, not for visibility of bugs which might highlight mistakes, but for the tedium of the task.
Testing is boring! Here, we are expected (rightly so) to test our own work. However, herein lies the problem; if someone has been on a project for a couple of months, the likelihood is they are suffering from some form of code blindness or tunnel vision. It happens to the best of us; while pixel perfection is something front-end developers need to strive for, sometimes, mistakes are made and go blissfully unnoticed. The first revelation by Patty was her insistence that dedicated testers being part of the workflow are an essential asset for any development team.
Quality assurance team
She highlighted that a member of the quality assurance (QA) team is on a project from conception through to completion. From conception, they know what it is they will be testing, so they have a full understanding of the project and the end user’s needs.
These testers don’t need to do anything during the design and some of the development of a project; they just need to be aware of it. They can be testing other things in the interim. To have a fresh pair of dedicated eyes on a project for testing, I feel will be an invaluable addition to our workflow. They will be responsible for the testing documentation, manual testing using a device lab, automated test scripts creation and importantly an attention to obscure details.
When it comes to testing itself, Patty had another revelation, something there are a lot of articles and resources about. We currently test by going over to the Project Manager’s desk and hoping the key holder is around. We then get out whatever devices we need from the cupboard and go back to our desks to begin testing! Of course, half the devices are dead and, of course, the cables are missing.
Sometimes, the devices haven’t been returned and you have to hunt around the office playing a game of “where is the iPad”, bouncing from desk to desk trying to trace its path. So how does Patty suggest we tackle this obviously irritating workflow?
A Device lab
We do have a good collection of devices here at Branded3, but it’s by no means a complete collection (if such a thing exists in the rapidly evolving market of devices). All the devices we have are currently locked in a cupboard, out of reach if the key holder isn’t around.
Such a simple concept – having a dedicated space where if you are testing, you go to test. All the devices are out, all the common operating systems and devices are there, as well as a few less common ones too and everything is plugged in!
I think this would make testing an oddly enjoyable task, not only because a device lab sounds like a cool place to hang out (I’m such a geek), but because it takes away frustrations we currently have; separating our physical testing environment from where we sit and do our work means we have focus. I believe a room or station dedicated to housing our testing devices separates things. We can fill in our testing logs and file bug reports then return to our work stations to tackle the issues.
There is a great post by ETSY on the subject of device labs and this image rings true to me. This is what we need to transition to, to make life easier for developers and designers.
Patty’s slides can be found here
Conferences are exhausting, often involving last-minute check-ins in strange cities, long-distance travel and, of course, the patience to sit and listen to people talk for hours on end. GenerateConf didn’t fully break this convention for me; I was exhausted by the end of it, but I was also incredibly motivated and excited.
Now bubbling with new ideas to bring to the team, I feel invigorated to strive for perfection, to make our team the best So, I say thank you to all those amazing speakers involved and to the people at net magazine for organizing it. I will be back at the next event, eager to learn!