As we start building software in smarter, more sustainable ways, the best new techniques and methodologies out there all share one core concept: .

Drop the idea that you are Atlas carrying the world on your shoulders. The world would go on even without you. Don’t take yourself so seriously.

– Norman Vincent Peale

Making web apps and digital products is difficult. There is an unavoidable amount of complexity involved and designing it. Developers and designers often feel very smart for working with (and creating) very complex things — and that makes sense. Doing complex things well is pretty impressive.

But complexity isn’t the end goal. In fact, your job as a designer or developer is to reduce complexity, not increase it to make yourself feel smart. As we get better at this whole making things with code thing, the industry best practice methodologies are shifting towards a humble acceptance that simplicity, although it might not make us feel smart, is sustainable, effective and in many ways, much smarter than complexity for complexity’s sake.

Doing something complex is impressive. Doing something complex and then making it simple is even more impressive.

Big Words and Long Sentences

I remember when I was a high school English tutor, I worked with a kid who had very little interest in writing. English, however, was a mandatory unit for his final exams so he had to at least pass. And that meant essay writing.

To start with, I read some of the essays he had recently submitted. Like many kids, he had tried to “seem smart” by adding a lot of Big Words and Very Long Sentences to his essays. It would read something like this:

Lady Macbeth was a character used by Shakespeare to effectively create exceptionally overwrought tensions in dramaturgy for the purposes of narrative advancement.

Essentially he was writing his thoughts as they occurred to him, then writing them again in a way that “sounded smart”, then looking up synonyms that sounded even “smarter” and replacing the shorter words with longer, more “impressive” ones.

Over and over I’d go through his work and get him to re-write sentences in the way he would explain it. To him, it sounded “dumb”. He thought that the way to be smart was to “sound smart”.

Over time, he learned that he could express complex ideas simply and clearly one he had gained a deeper understanding of them. He eventually looked back on his first essays and chuckled.

Back in the land of 

Much of the same complexity theatre exists in the tech world.

Building an app out of a set of self-contained building blocks is simple, but a challenge to the egos of devs and designers who for too long have built their careers, self-identity and sense of achievement based on lines of code, hours spent slaving over a hot pull request or number of layers in endless PSDs.

Designing a system that allows for simplicity is harder than you might initially think, but in doing so, it allows us to build software that’s stronger, more flexible and much easier to work over time.

So here are some simple ways you can drop the ego and build better stuff.

Tips for developers

You make mistakes: use version control

Related image

This one should be pretty obvious.

The thing about version control is that it has saved my butt many times. We don’t just use git to collaborate with teams of other devs — we also use it to manage our own workflows and go back in time to step through your work so you can rebase to a time when you didn’t break the app.

Shocking revelation: nobody is so at writing code that they get everything right the first time. Prepare yourself to make a lot of mistakes. Use version control and commit often so you can go back in time if you break things.

You don’t have endless time: submit better pull requests

If you haven’t noticed, there’s a LOT going on when you’re working on a technology project. Increasingly, we’re expected to be writing code, reviewing code, involved in non-code things like meetings and research, etc.

Everyone is busy. One of the best things you can do when putting up pull requests is giving as much context and relevant, reviewable info as possible.

There’s a fine line between not enough info and TMI, but it’s worth talking to your team about what’s the right amount of context to add to a pull request.

Keep in mind that non-technical team members (or semi-technical) should have visibility over PRs too, so adding screenshots, user stories, and steps to test should be a baseline for every bit of shippable work presented in code.

You’ll forget about the edge cases: write more tests

So, I find writing tests so boring. I’m a frontend dev, and tests rarely have any visual output, so I find it absolutely mind-numbing. That said, I know it’s super important because as much as I want to say I’m the most excellent frontend dev that ever walked the earth, I’m not, and probably neither are you.

Image result for TDD

We are fallible and biased — we build things and forget about some of the states they’re in. Only later on, through some sort of usability or user testing, do we find out about the “edge cases” that we missed.

Rather than hoping that you’ve thought of every permutation — write tests. Write tests that throw different kinds and types of input at your components, write tests that check for elements being visible and clickable on pages (using something like Ghost Inspector if you want). But write tests, not because someone told you to, but because you know that tests help you keep track of your assumptions better than your brain can.

You’re not good at separating chunks of work from broader context: develop in a styleguide first

This one is a bit of a paradigm shift for many people. The way we used to do things was with a ton of PSDs and layers, and we built websites page by page.

Now we build things component by component. We know that we can’t actually build each page — with CMSs, dynamic content and web apps, most things that users see will be unique, not static. We need to build things as a collection of flexible, pluggable components that work together under various circumstances, including changing content, devices and user settings.

The idea that we can build new components just directly into existing pages is pretty flawed. How do you know if your code is properly encapsulated? How do you know that the component will work in other contexts? How can you properly review all the states the component will be in?

Building things outside of the main app (and instead in a style guide or component library) is a bit of a shift in your workflow but boy does it make your work better. You can properly visually test your chunks of work for logic, visual changes, style encapsulation and reusability and state management.

Watch this, it will change your life:

You’re bad at managing monolithic complexity: use components

The industry wide shift to component-driven development is so excellent for so many reasons. Firstly: reviewing giant chunks of work in 1000+ line PRs is a nightmare. It’s a classic Agile concept to break things down into small parts, not just for the sake of it, but because it’s less cognitive load and humans are just rubbish at handling huge amounts of information at once.

Secondly: products are dynamic and require systems thinking. Gone are the days when pixel-perfect PSDs had to be hand-coded element by element so each page perfectly matched the designer’s vision. One page layout now supports a multitude of different pieces and types of content, devices and contexts, not to mention potentiality for user-driven configuration.

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md

To design effectively for the unknown future state of the content in a user-driven CMS or product, we must adopt systems for design and development. A design system and component library helps us conceive of some way to build new pages and features without reinventing the wheel every time — and as a result, even though an investment is required up front to convert a monolithic design/codebase in to a design system/component library, the speed increase over time is only logical.

Tips for designers

You don’t know everything (yet): do user research

Hey you! Yes you, person who has worked at your company since the dawn of time. I know you have a lot of knowledge about your product — and probably a long list of things you’d like to make better. You care deeply about your users and the success of the organisation overall.

But guess what homie? You’re not the authority on what your users want. Your users are. Complication: you can’t just ask them, “Hey users, what do you want?” because they’re going to say something like “HOVERBOARDS!!!” and that’s not helpful. You have to do the Jedi Mind Trick of User Research™ where you ask your users the confusingly perpendicular question of “What problems are you struggling with?” or even, “Tell me about the last time you had this kind of problem?” and then your team is responsible for designing a real clever way to solve that problem.

Yeah, it sucks: everyone has this niggling feeling that if only other people would just trust them they’d change this one thing about the product that would revolutionise it, but only some people — usually designers, who are highly trained to understand the differences between personal preference/opinion and design rationale/heuristics — should really be trusted to act on their instincts.

That’s not to say there’s no place for your instincts. There is. You should talk about them. Instinct is really just internally synthesised research. But stop relying on your gut feel 100%. It’s disempowering to others, it causes the loudest/strongest personalities to drive design decisions, and it’s a little narcissistic. Admit it: you spend most of your time doing completely different activities to your users. You might have some stuff in common with them but even if you pay for the product yourself, you just have too much context that they don’t have to be able to act as a perfect proxy for their needs. Go talk to some users. Go ask them if your designs are successful. Stop making assumptions.

Sunk cost fallacy is real: think before jumping into high fidelity designs

You might feel really smart and productive and busy and like you’re earning your cold hard cash moneys when you’re slaving away over a hot PSD or Sketch file, but your obsession with taking everything to high fidelity to get the “ooh, ahh” reaction from your boss or stakeholders isn’t making up for all the downsides of hi-fi design.

Sunk cost fallacy is so, so real — people become less likely to suggest changes, offer feedback or collaboratively design as your deliverables get higher in fidelity. If you want to leverage your team’s expertise, jumping straight to hi-fi is not the way to go.

Moreover, it’s almost guaranteed that your effort to precision ratio is not good. You can spend ages working on mockups and still miss heaps of use cases, breakpoints, content variants and animation subtleties.

Software is complicated and quite frankly cannot be fully expressed in a flat image: stop pretending that your mockups are a good guide for devs. They communicate what something looks like, but they do a bad job of indicating how it should work.

You can’t think up the best ideas on your own: run a sketch shop or design studio

Good designers understand that they’re not the gatekeepers of good ideas. Good ideas come from all corners of the organisation — but usually only occur when they’re prompted by the right background information and context.

Even if you refuse flat-out to work with others (why? who knows) you should at least try to come with a few ideas on your own. Better yet — get a few people to come up with a few ideas each. They can then select their best idea from their ideation and then flesh it out, and together you can discuss the pros and cons of different people’s ideas.

Who knows, maybe your idea is the best — but why not hear other people out? Someone else probably has thought of something that you haven’t, because we’re not all the same person.

We each bring a different background, experience, culture, personality and style to the table when we are creative. Different people have different go-to’s when solving problems — and that’s a good thing, not a bad thing.

Depending on your cultural background you might store ketchup in the pantry or the fridge, and therefore when you run out of ketchup you may replace it with spices or mayonnaise, respectively. Instead of making these differences in solution ideas into arguments, we can use collaborative design processes to leverage them as an advantage. Don’t assume your solution is the only or best one.

You can’t build perfect UIs from scratch: make a design system

I do not miss the days of being handed a PSD and asked to make it a website.

If you think your PSD/Sketch file/PDF/jpeg is a good enough deliverable for a developer to implement, you’re wrong. I know it’s hard to accept. You probably put a lot of time into that, naming all the layers, building all the buttons from scratch, hand painting all those form fields… but the truth is it’s not even that helpful.

Why? Because the internet isn’t static. People resize their browser windows, view websites on all sorts of wacky devices, have slow internet connections, put in all sorts of content and that’s just the start of it.

The web is dynamic. Your mock up is static. Design for the web needs to be fit for purpose. That’s where design systems come in.

A design system is the evolution of the style guide. It started as a kind of mood board for your high fidelity designs, or even a set of reusable chunks of high fidelity design like buttons, cards etc. Recently, we have shifted to skipping hi-fi and making those little reusable chunks actual pieces of code that can be dropped straight into applications. They’re called components.

Design systems are component libraries. For a time we talked about “sharing” components between design and dev — like what if those components could be used in Sketch as well as in React? It’s a nice idea, but in fact there’s a faster way — skip Sketch and design in browser.

And so now we have DesignOps, where we are working towards a world where code is design and design systems help us build consistent, shiny, performant UIs very quickly. As a bonus you can skip the “design feedback and approvals” step because the thing you’re approving is the final form.

Hand-painted, time-consuming UI mocks can never encompass the amount of variation, the range of content, the various contexts in which a digital asset will be displayed. Make a design system and stop wasting your time.

You’re probably wrong even after you’ve done heaps of other good stuff: do usability testing… frequently

Usability testing is just this crazy idea that maybe you should show someone who uses the thing you’re making the thing so you can get their feedback on it before you barrel forward. It’s so uncommon, but it’s so drastically important.

The lack of usability test comes from a few places — firstly, it’s a little more time consuming than “looks good to me, ship it!” or “the boss likes it, ship it!”. Secondly, people don’t really know how to do it or what to do with what they find — especially if the results are “nobody gets it and they hate it” but you’ve already promised to deliver it. And lastly, people just think they know everything.

This is the thing: people who have worked at organisations for a long time (with the biggest offenders being usually founders, sorry founders) tend to believe that just due to the amount of time they’ve spent with the product that they just know exactly how everything should be/look/work.

To be honest you probably do have a lot more context/history/memories/relevant ideas than someone newer to the company, but unfortunately that still isn’t the same as having lived experience as an actual user of your product who is actually using it to solve their actual problems.

You, technical person who builds the product, have lots of good input but you just can never be the proxy for the actual experience of genuinely using it.

Usability testing, despite how much people avoid it, can be quite simple. It allows us to go to the people who use our products (or even people who don’t use them, i.e. people who are just not us/not in our little bubble) and find out from them directly if they’re usable.

It’s a simple format where you essentially put a design/prototype/asset in front of them and ask them to use it unguided while speaking aloud. It allows you to experience first hand what it’s like for someone who hasn’t been in all the meetings about the thing to use it. They don’t know what the words mean, or where to click, or how to exit, or how to recover from that errors — mainly because you and your team have all that important contextual knowledge and you forget that other people don’t.

Stop assuming that everyone else knows everything you know. Go find out how your products actually come across to people who are not you. You’ll make a better thing as a result.

Tips for product people

You don’t know what people will buy: test the market with Jobs to Be Done

People are difficult. It’s hard to know what they want. Sometimes they use things you make and it’s hard to even know what they’re using them for.

JTBD does something radical in that it forces us to step back and admit that just because we can see people doing things, unless we know why they’re doing those things, we don’t know how to make improvements.

You’re bad at estimating and planning in the face of uncertainty: embrace Agile methodologies

So old school project management is amazing in many ways but for the world of software where everything is simultaneously on fire to varying degrees of fire, it makes literally zero sense to try to write out all of the possible requirements, risks and estimations before anyone has written a line of code.

You may find comfort in a Gannt chart but it’s fake news. The truth is that every action you take creates new risks, new requirements and new complications that will inevitably blow our your perfectly crafted project plan.

Agile has given us ways to execute projects without the burden and theatre of massive amounts of up-front planning, with short iterative cycles, light-touch estimations and collaborative scoping. It’s all based on the idea that nobody is good enough at seeing into the future (or understanding probability) to do a good job of predicting the outcomes/timelines of any project so don’t bother. Every minute you spend doing that is just hubris.

The #NoEstimates movement has even thrown the idea of story points out the window, instead looking at just number of tasks completed as a good, low fidelity metric that gets you a lot more bang for your buck than anything else. There is a cost to up-front project management, and you should weigh up that cost against the rewards (which are often so few and far between).

You’re not a prophet. Stop trying. Just get started and adjust course as you go.

You tend to lose focus and get distracted: prioritise ruthlessly

So, when was the last time you achieved great success by trying to do a million things at once? Probably never. We’re equally ambitious and anxious: we want to get so many things done, and we want to get them all done right now.

It’s upsetting, I know, but the best way to get a lot of things done is to just do one thing at a time. As a parallel to the ideas suggested in The Mythical Man-Month, specifically that “adding manpower to a late software project makes it later” — increasing your WIP limit doesn’t make your velocity/throughput better.

In fact, every moment you spend working on things that aren’t your top priority, you’re wasting time. You might look busy, but you’re not being effective. Stop it.

https://jamesclear.com/buffett-focus

Smart people know how to explain themselves: learn to collaborate cross-functionally

Here’s one that baffles me eternally: some people think it makes them seem smarter when they’re harder for other people to understand. I used to tutor English to high school students and so many kids go through that phase where you start adding long words to your essays in an attempt to seem intelligent: news flash: it makes your writing harder to understand and makes you look kinda silly.

Surprisingly, even some of the most senior executives I’ve worked with have leaned in hard into domain specific terminology, otherwise known as jargon in an attempt to seem like they know their shit.

It really doesn’t help anyone for you to just reel off a bunch of acronyms, buzzwords and neologisms. It makes it harder for people to get to the crux of what you’re saying quickly, and it displays an overall lack of empathy for other people.

If you can explain the really complicated smart thing you’re doing to your mum, then you’re smart. Stop trying to baffle people. We see you.

Importantly, baffling people with DSLs inhibits cross-functional collaboration. It should be self-evident at this point that doing anything in a contextual/disciplinary bubble will lead to short-sightedness, stifled creativity and bad decision making, but still some people refuse to step out of their comfort zone and work with the people across the office.

In my experience anyway, the best ideas come from mixing paradigms. In Designing Your Life there is an idea called “reframing”, where you can look at a problem through a different lens in order to see a new way to solve it. In The Creative Tarot, Jessa Crispin explores the idea of using a paradigm like tarot to help unblock and solve creative problems.

Read widely, learn the lingo, break it down and go outside of your comfort zone. The best ideas almost always come from somewhere outside of your current solution set. If you think all the best ideas come from your own brain, you’re dreamin’.

You can’t communicate context in a single meeting: stop doing handovers

You know what’s the worst meeting ever? The handover meeting. If you think you can connect two silos in one hour with perfect results, you’re absolutely dreaming. Handovers don’t work because if you’ve been working in secret for weeks, too much has happened to be effectively communicated in such a short period of time.

Instead, work collaboratively from day one. The first think you should do at the start of any piece of work is assemble your A-team — identify all the collaborators you need to be successful.

Don’t split the team into “decision makers” and “delivery” — this is where most people seem to go wrong. This division seems to be based on the idea that “decisions” should be made by the people in management position, and be the delusion that no more decisions will get made after the allotted decision-making time has ended.

In truth, the people delivering the work make various decisions — as do the people prioritising the work. I’d go as far as to say that all of these decisions are what we should be calling “design” — and you should be taking the design process at your organisation very seriously.

So stop doing handovers. It’s based on the misconception that all the decisions you make at the start of the process are the most important ones and only you and other “senior” people should be involved, and that you are good enough at communicating that you can hand all the context over to the “delivery team” in one fell swoop. You’re not that important and you’re not that good at communication, nobody is.

Tips for organisations

Not everyone thinks the way you do: invest in a code of conduct

This is the important follow-on to all of the bits above. The overall theme you should be observing is “not everyone knows what’s in your head”. This goes for behaviour and values as well.

I have worked at various places where people were let go because they “weren’t a good fit”. This would be fine if anyone could tell me what a “good fit” actually was, which they mainly could not.

For a lot of orgs, “good fit” too often means “someone just like me”, which not only is unrealistic but also won’t really get you to a good outcome. Hiring people who are just like you comes from the amazingly egotistic idea that you are the best possible person for every job (or any job, really).

As we’ve already been through, you really want to be working with people who are different to you if you want to be building great things. But the key issue is that people who are different to you are actually different — they have different backgrounds, histories, experiences, cultures and values, and as such you need some way to make sure diverse teams can actually agree on rules of engagement for collaborating in a business setting.

That’s where you code of conduct comes in. It could be as simple as some examples of how your company values should be implemented in reality, or you could go more hardcore legal. Regardless, people aren’t necessarily going to “intuitively” understand how you want them to act in every given (and potentially difficult/stressful) situation.

People not acting the exact way you expect is not necessarily their fault. It’s possibly your fault for not being clear about what you expect.

People need all the puzzle pieces: share context and increase transparency

If you hide all the information in private chats, people can’t access it. Without access to the important context, people can’t do their jobs.

via Jessica Kerr https://twitter.com/jessitron/status/1020073347734896641

It really is as simple as that. I’m not sure what more I need to say here.

I’m shocked at home much many orgs think they need to hide from people. It is invariably too much, and thee people on the “front lines” of your org end up just guessing at how to do their jobs in a way that will make the company leaders happy.

It’s absurd and it is a waste of time.

Default to transparency and stop people from guessing at what “good” or “effective” is. Show them the goals, show them the context. Look at OKRs, look at other ways to make it crystal clear what is the most important thing any person in any role should be doing at any given time. If you think hoarding information is helpful because you’re so smart and senior that only you could possibly know what to to do with it… consider not doing that.

There’s no point guessing: hold regular 1:1s or suffer

Amazing that this isn’t regularly practiced. So many managers and leaders think this is a thing that “big companies” do and don’t do them. Yes, for you, the manager, it is a significant time investment to meet with all your direct reports for an hour each every fortnight or so, but the ROI is massive.

There’s just really no excuse for not doing this. You miss an opportunity to listen to the people on the front lines, and to give them important context they need to do their jobs.

It’s not hard. Start with Michael Bungay Stanier’s seven coaching questions and go from there. It will pay itself off in no time.

If you think you can manage people without 1:1s, you’re a terrible manager. Just go talk to people. They know stuff that you need to know.

In summary…

  • This is an extremely long blog post, I apologise
  • All this “buzzwordy” stuff like “Agile” and “listening to people” and “being a human” is actually only possible to do properly if you are humble and empathetic
  • Transparency is easier than double handling
  • Context helps people do things better
  • Don’t assume people know what you know
  • Drop your ego, be more humble, build better things — you might even make the world better.





Source link https://blog..io/humility-in-tech-for-the--good-2d6cb6249709?source=rss—-eb297ea1161a—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here