2. What am I
talking about?
There doesn’t seem to be a goal
Scope changes rampantly
Features creep
Buzzwords rule your life
Who’s a designer? Everyone!
“We don’t have time for docs”
Communication is strained
You’re not getting paid
What happens when:
3. Who is this for?
The lonely
Developers with good
intuition and too much
imposter syndrome
People who think they’re
project manager (a
weekend scrum course
doesn’t count)
Anyone who’s ever worked
for a 22 year old
Frustrated people
6. Scope creep is what now?
Scope creep (also called requirement creep, function creep, feature creep, or
kitchen sink syndrome) in project management refers to changes, continuous
or uncontrolled growth in a project’s scope, at any point after the project
begins. This can occur when the scope of a project is not properly defined,
documented, or controlled. It is generally considered harmful.
-Wikipedia
7. You may have scope creep if you:
Experience countless and endless meetings about what’s
been planned already
Are taking customer suggestions individually and literally
Customers are important, but they often don’t know exactly what they want,
they just have a feeling
This is the whole point of UX design, hire a UX person if this is confusing
Never know what’s going on
8. Scope creep can be avoided by:
Planning early on
Understanding user needs
Emphasising time/effort needed for features:
X will take Y amount of time and cost $Z. You sure it’s necessary?
We’ve spent 10 years on this one feature already, does it really need to
catcall my mother on page load or is that an edge case?
Having milestones (both short and long term)
9. So that didn’t work…
Here are your options now:
1. See if whoever’s causing the problem can focus on something else and let
you work
a. You know what’s up, you just need time to do it uninterrupted
2. If you’re at a company with a hierarchy, and can reasonably ask for help from
higher ups, try that (mention the money they’re losing)
3. Quit
a. Find somewhere sane to work
b. Optional: worry about your ex coworkers’ families
12. What is documentation and who cares
Can encompass code details, execution, as well as planning
resources
Is immensely useful as a communication tool and common
reference
Solves a lot of the aforementioned scope creep issues
Removes the “Bus Factor”
Only one exception
13. So you have no docs...
Write them yourself
Can be a good learning experience if you’re new to a project
Ask lots and lots of questions
Write down the answers for yourself and future generations
Get hit by a bus
That’ll show them
Make sure you’re important first
14.
15. So it thinks it’s a
designer
Proof is in the pudding
16. No design is better than bad design
Design is an important part of the planning process
It’s fine to not have a designer on hand in a small company
It’s not fine to cobble things together
If you can’t make things pretty, then don’t. Make them work.
This ties heavily into scope creep
17.
18. Bad attempts at design can be avoided by:
Hiring a designer (at least part time)
Using proper tools for design
Photoshop is still great (particularly with apps like Invision)
Having examples to point to that everyone understands
Show your friends, make them be mean
Sticking to a style guide
19. So that didn’t work...
Bad design may seem trivial, but project success can hinge
on it
Try your best to magic up something attractive
CSS animations are snazzy and keep people from complaining
KiSS
Copy nice things
Convince your “designer” it was their idea
23. Oops, that transfer didn’t go through, et al.
Paychecks are consistently late
There are whispers/roars of investors pulling out
You need to find out why
Expenses aren’t being reimbursed
Pretending severance pay isn’t a thing
24.
25. Getting paid
Know everything about your employment status
Not much to be done if the company doesn’t have any
money in the bank
Follow up early and often
Stay calm but be firm. Know what’s owed.
If unresolved:
Ministry of Labour
It’s hard to speak up sometimes. You may be new at this, but if you know something’s messed up then say so, worst case is you’re annoying for a week while things are clarified
Everything thinks their way is the best, and what’s clear in one person’s head can be nonsense to someone else. A real / good PM knows how to convey information using familiar tools and procedures. A bad PM thinks that saying the words “Agile, SCRUM and Iteration” means they can get away with whatever.
Young people are the worst (sorry Lauren)
Long meetings mean people don’t know what their targets are. No agenda is a bad sign.
Customers are great and some have awesome ideas. However, there’s a special skill that comes with hearing out a customer suggestion or complaint and reading between the lines to turn it into something feasible to solve. Suggestions like “it needs more buttons” aren’t necessarily to be taken to heart.
*side note: Also beware of phrases like “Our customers want X” or “They’re used to X shitty thing, so let’s not break the mould.” Again, good UX breaks with convention where necessary in order to make things more intuitive and clear. Otherwise flash intros would still be running rampant. Old and familiar !== right.
“Iterative” means sketching out a painting before painting it. It doesn’t mean 6 attempting 6 Jackson Pollocks one after the other.
If you’re starting a project, create comprehensive user stories, plan for sprints, plan for iterations, create mockups: Do anything that minimises developer confusion and can aid in creating a cohesive picture. This doesn’t have to be the be-all end-all but thinking through things thoroughly early on can help fix issues before you come to them
Know your users, make sure people working on the project know the users, know what they’re trying to achieve with your app at a really fundamental and basic level.
Framing things in terms of dollars spent can save everyone a headache. For example, “Yeah, we can redo the entire nav to give people 100 options to get to the same page, or we can put a big ol’ button in it. Button takes 1 minute, oddly constructed nav will take a day, and set back all other development by a day. Pick one.”
KISS
Goes with planning
If nobody is listening to the above make a list of everything you’ve been tasked to do. Sit down and cross stupid things off the list. Come back with fresh list and say it’s been ‘optimised’.
So you’ve tried on your own to kibosh this and get something done. Maybe some stuff stuck, but you’re still dealing with constant reevaluations, people are getting frustrated (including the creepers), and you need to ship something yesterday.
The simple README file in github counts. A single page of “this is how you run this thing” can be immensely useful for onboarding as well as show and tells to other team members.
Keeping things commented throughout your code is universally understood to be useful. That whole “The only people who understand your code are you and god. In 6 months it’s only god.”
The less you have to explain the faster you can get working with someone.
IMO Scope creep is 50% forgetting what has already been decided. Having it written down clearly and concisely reminds people that features have already been decided, code has already been written, architecture has already been laid out
Docs are boring but necessary. The phrase “we don’t need documentation” will eventually lead you to drink. Any project that’s going to scale needs to have some centralised place where things are planned and referenced, no matter what PM paradigm you’re going with. Even a small project should have at least a text file with app goals, a TODO breakdown, and some instructions as to how to run in development.
Only exception is “Self documenting code”, i.e. code that’s so clear to even a beginner that it doesn’t need to be described or referenced anywhere. This only works when a single developer has done everything start to finish or has mind melded with the rest of the team, or if it’s a TODO app. Everyone knows what those do.
If your company can’t hire someone to design (preferably someone who knows good UI AND how to code html/css), or has people who think of themselves as such but maybe haven’t updated their skill set since the 90s, consider running. Design is something that nobody thinks about unless they’re doing it, and the it’s something that can bog down a project if it’s done wrong
No design vs bad design:
Design issues cause investors, clients, and unimaginative team leads to get stuck on style guides and the general aesthetic of an app rather than working towards functionality. It’s also the first thing that people comment on because visual storytelling is what people understand in general, not code (even other coders). UX is paramount, the colour of your buttons is secondary.
Story:
Worked with someone who did lots of design work in the late 90s/ early 2000s. He had a controlling roll in the company. Had no clue as to modern tools, didn’t have modern CSS skills, couldn’t contribute to actual app design, and who’s process was basically asking for vague things then getting angry it didn’t look like it did in his head.
Finally got him to put some things down in UXPin, a tool which he misunderstood, and proceeded to do things “90%” of the way design-wise but expected the app to look 100% like it plus 10% magic thought design again. His ideas were impossible to satisfy, his prototypes dind’t make any sense in terms of user flow, there was no cohesiveness, and the overall look was blander than bootstrap.
In a case like this what would have been ideal is a fleshed out user story, maybe some notes as to what goes on which page, and some examples of a general style or style library. What ended up happening was we used 3 different style libraries in 6 months, then wrote our own, then got reprimanded for taking time to write our own (which had been approved beforehand), got reprimanded for it looking too much like the (obviously) horrible prototypes, then reprimanded for making it not enough like the prototypes.
I know “no design” as a thesis is a weird thing to state, but check this out:
Case in point:
This sucks, but you know what’s going on
as someone who admittedly sucks at design, I can do these last ones to get by and launch something acceptable.
Be wary if:
Lots of companies hire workers as “contract” workers full time, then dictate things like the terms of employment, weekly hours worked, and hourly pay. Contract workers set their hourly rate beforehand and often have their own contracts drawn up. If you signed something that says you must work x hours per week indefinitely at a rate dictated by the company, you’re likely an employee and have the same legal rights as any other employee (including vacation pay and severance). If you’re truly a contract worker make sure your agreement is airtight.
Find out if that’s the case or if it’s just logistical. If a company is young and just hired a bunch of people they may be migrating payroll software. This is acceptable (short term). If they actually have no money, depends on where they are. If you’re at a startup, you believe in it, and don’t care about money, then equity is a temporary option. If there’s money that’s about to roll in in a big way and you want to wait to see if that happens, that’s always an option and could be a big pay out.
Ministry of labour can do an audit for you, but it takes time. The mere threat of it might be enough to get you what you need, but most people have already thought of that and either think they’re right or are willing to take the risk.
Legal action can get expensive and take months. Unless you have a 100% solid case that can be taken to small claims court, try to avoid. Exceptions are for lots and lots of money, where the payout is worth the time, or for gross injustices.
All of these issues are common even at good companies individually, but rarely in combination. Every one of them also needs to be considered in context.
I don’t want you to quit your job if you love it despite organisational nonsense.
A lot of the “solutions” provided mean taking more of an initiative with the company or team in order to pull it out of chaos. It takes a certain kind of personality to want to do this, and to take on the risks associated with more responsibility. Responsibility = culpability, so there’s a good chance that if the situation is unsalvageable you’ll become the most immediate scapegoat.
If this happens, you need to have a thick skin and remember what you’ve learned going through it. And if the risk of blame keeps you from trying to fix things, remember that you might still get blamed, as a developer, or just by being involved, for a failed project. Up to the individual to assess what the best thing to do is, these are just ideas.
Don’t outsource to India or get hit by busses.
