MVP for design teams

I work with growing software startups who want to start doing design properly. They often seem reluctant to invest time or money into UX and as a result I’ve repeatedly seen the design practice fail to launch.

Milly Schmidt
13 min readNov 30, 2018

I’m pitching an MVP for resourcing a new design team that allows you to effectively kick-start a functional design process and see results faster.

Is this you?

You’re a software startup looking to hire your first designer. Maybe you call the role “UX designer” or “UX/UI” or “product design” or even “product manager” but the fundamental need is the same: someone is now too busy to make decisions about what your product does and looks like.

Perhaps it was the founders or the CEO who was calling the shots about how things should work or look. Or maybe it was the engineers, who are pretty familiar with this stuff and know what software should do. Maybe you didn’t even call it “design”. Or potentially you hired a brand/graphic/visual/print designer, who put together some beautiful mockups in Photoshop/Sketch, but now you’re struggling to make that process scale.

Perhaps you’ve hired a few engineers and they’re sitting twiddling their thumbs waiting for designs. Maybe you just want to see what all the fuss is about with this “UX” stuff that everyone’s talking about; or you’ve read about “design thinking” and it sounds like it might stop some arguments; or you’ve been geeking out on “Lean” and thought it might help you ship stuff faster that makes your customers/users happier.

So you hire a designer — some flavour or UX, UI, product or front-end. They seem so right for the role — a great T-shape, with skills in facilitation, wireframing, high-fi and low-fi designs, research, leadership and even strategy.

But as time goes on, you notice that they seem to be doing a lot of random stuff… and not all of it you approve of. They’re rarely at their desk, and they spend a lot of time helping other people. There aren’t many deliverables you can attribute to them directly. They keep talking about needing more time but it’s not clear why — the main deliverables for this role are pretty screens, and that shouldn’t take too long. The visual designer who used to work with you always turned them around quickly.

And all this research stuff, it takes a long time to organise and complete, and all you ever seem to get out of it is confirmation of stuff you already know. You feel you have pretty good instincts for design, it doesn’t really seem necessary to go out and talk to that many people. It just takes so long!

One other big thing that’s missing is a broader design strategy. See, your CTO has put it together for engineering and your CMO has got one for marketing — it’s odd that this supposedly senior designer hasn’t stepped up to the leadership plate with a strategy for design. I guess they’re just not leadership material. Oh well, as soon as they start unblocking the devs on UI stuff it’ll be worth it.

You’re not sure why you keep having these issues with designers — the role seems pretty simple, in fact you can basically get by without a designer (you did before, right?).

Set up to fail

It’s a story I’ve seen unfold a few times — design’s failure to launch at startups that seemed keen and ready for it. I’ve spent some time reflecting on my own role as a “first of my kind” designer, and on how different companies have played it out with different personality types, products and industries as backdrops.

My suspicion — and the case I have made to management at these organisations — is that for design to be successful, you need an MVP that’s actually going to be able to deliver value, and one person is not enough.

Challenges for startups bringing in design for the first time

There’s a big difference between joining a mature design team and joining a non-existent one, but everyone has to start somewhere.

For startups looking to turn their make-do design approach into something more in line with industry-standard practices, there are some specific challenges that tend to come with the territory.

  • Technical and design debt
    Without good designers on your team, you’ve probably made some bad decisions. Likely there’s a lot of design and technical debt to work with, which a smart designer will work on quickly paying down. This may not be what you want, but a sustainable and scalable process has to start here.
  • Historically hiring designers with the wrong skills
    You might not have known much when you started out, and that’s OK. You’ve probably had designers (who may or may not still be working with you) who leaned more towards graphic design than UX — which means you’ll likely have an immature research and validation process, and a lack of systems thinking across your design ecosystem. A senior designer will want to spend some time establishing more effective processes and techniques like establishing a rhythm of research, collaborative feedback loops, design systems and some more early-stage input than you’re used to. They may even start making changes to things that are visually/aesthetically inconsistent, which could make you feel like you’re losing some pizzazz.
  • Looking for a silver bullet superhero
    You might also be used to someone working largely on their own. They may have offered you revisions, but largely it was a handover process to and from the “design stage”. This may have set you up to believe that your next design hire will work in a similar way — basically a superstar who will come in and revolutionise things as well as spit out deliverables at high speed. As tempting as it is, the truth is that this isn’t what good design looks like — it’s a lot less glorious and a lot more collaborative, messy and iterative.
  • Founders are “too close” to the design process/decisions
    At the early stages of getting your startup off the ground you likely did a lot of the design work yourself. That makes sense. But now, as the company has grown, you have to step away from that work and let the people you hired do their jobs. Many founders find this hard, and in particular find it hard to trust people to do things the right way. The challenge is to provide them with the right context rather than get mad and swoop when they can’t read your mind.
  • Sunk-cost fallacy
    Sure, you made some mistakes. Everyone does. But it’s dangerous if you feel too attached to the design decisions you made before you really knew what you were doing. You may even feel like even though things weren’t perfect, you don’t want to throw out what you did and waste all the long hard hours you spent. This can make it really difficult for new designers to unpick mistakes, assumptions and history.
  • Overvaluing aesthetics
    It’s so easy to be swayed by a shiny UI, right? That flat design look, pretty animations, lovely colours — for founders, having a product that looks beautiful is so important, especially if you’re shopping it around to investors. You just want to feel proud of it, right? It’s an easy mistake to make, valuing aesthetics over true usefulness — and you may be surprised when a senior designer comes in and tells you your design isn’t great when you think it’s beautiful. But making something that’s usable and useful is much harder than making something pretty, and a real design practice will help you get there.

The design team MVP

The MVP for design to start “working” at an org is at least three people: one UI designer/front-end dev, one UX researcher/product designer and one design/product leader.

This MVP team idea comes from these core principles:

  • Never design alone
    One designer just can’t do a good job on their own, no matter what part of the design thinking process they are at. You need (at least) two people at a research interview, you need many ideas and contributors for a sketch workshop, you need a team for synthesis, you need peer review for all forms of low and high fidelity UI design. Doing these things as the sole designer means that you lack anyone to “bounce off” — and to draw a comparative example, one developer will always struggle, but two developers can review each others’ work and generate ideas together.
  • Management is a real job
    Startups tend to find management (as well as research) “too expensive”, and then complain that people aren’t performing or that they’re having communication/alignment problems with their teams. Asking people to manage/be strategic as well as execute/create deliverables is a bad idea — it undermines both disciplines. Management is a commitment to a function within an org — and to the people who are working there. For an emerging discipline, it allows someone to think strategically, engage with and educate the org and manage process changes.
  • UX is not UI
    UX ≠ UI. User interface designers have a very specific skill set, and are patient, careful pixel ninjas who work with high fidelity tools to produce beautiful assets. UX designers don’t necessarily do that. UX research is a specific and deep skillset that a UI designer won’t be quite as good at; conversely at UX researcher/facilitator won’t show as much interest at slaving away over a Sketch file. Different people, different personalities, different skill set and fundamentally different roles.
  • The distance between UI design and development should be as close as possible to zero
    If your UI designer can also write valid markup and CSS, you’ll save a huge amount of time trying to “translate” and “hand over” high fidelity assets to the engineering workflow. UI/front-end helps create a more efficient delivery workflow for teams and puts all things aesthetic and interface together to create a role for a detail-oriented person obsessed with designing and building user interfaces. It just makes sense.
  • Do one thing well instead of three things poorly
    This applies more broadly than this issue, but splitting your focus three ways isn’t a good way to get things done, and certainly not a good way to get it done to a high standard. Forcing people to spread themselves too thinly sets them up to fail by making sure they don’t have enough time to do anything properly and creates heaps of efficiency problems from context switching.
  • Good design is more than aesthetics
    So, you want more “design” — you want everything to look amazing and be super intuitive. Sadly, you don’t get to be Apple by just hiring a UI designer who likes Apple designs. Well-designed products are more than just aesthetically pleasing — they’re built to perfectly match and serve their users and the only way to do that is to research and test, a lot. Well-designed products really work and really solve problems for real people. Just adding the pretty won’t fix your deeper design problems.
  • Design debt is real
    I get it, startups have to get off the ground somehow — often that means just going with your gut or copying a style you like or working with the resources you have, but the truth is — and sorry, founders — even though it was an exciting time where you got to flex your creative muscles, immature design practitioners create design debt, in the same way that outsourcing or hiring junior devs can create tech debt. And in the same way as tech debt, if you want to start doing things at pace, you’ll need to clean up that debt as well as build new stuff.
  • Design shouldn’t fight the business model
    If there’s no real need for design at your org, don’t hire designers who want to build a strong practice. For example — maybe you like things to look a certain way, but its not right for your users. Or, maybe you make all your money from advertising and the UX of the product/website has no impact on your bottom line. A strong design practice connects to the goals of the business — you need to learn enough about design to understand whether you actually need it or not before you go wild hiring.
  • Investment, for real: time, money and power/influence
    Further to the point above — it’s not a lot of fun being a designer somewhere where design isn’t valued. What does that mean? Quite simply, your org needs to value design as a function/discipline — in the same way that you would value development by hiring devs, having technical managers and paying everyone good wages, the same is to be said for design. Some indicators for valuing design include allowing design to be part of strategic/business level decision making; understanding that design is more than making the UI — and in fact more than making product — and has applications and value across other parts of the organisation; competitive salaries; trust and respect for designers (don’t hire your first designer and then tell them how to do their job; let them educate you).

How the MVP works

My theory is that this MVP of three will be a better approach for the individuals and for the organisation overall, and that it will result in a more effective and impressive design function that will starting paying for itself — rather than one that struggles to get off the ground and burns people out.

It’s based on the basic idea that UX, UI and leadership are different skills and being excellent at all three is unlikely, but being able to do all three things is vital to establishing a strong design practice where there previously was none.

Without this investment, I believe organisations risk investing something that can’t function properly — it’s fundamentally not ready for market (i.e. it’s a burnt pizza MVP):

So without further ado, here’s how I see the roles working.

Design/product lead

Key responsibilities:

  • Helps educate and train the organisation about design thinking, Agile, Lean and other methodologies
  • Works closely with senior/executive leadership to turn business needs into design/product goals
  • Hiring designers and design practitioners
  • Works closely with other functional leads to integrate design into other organisational disciplines and practices (e.g. marketing, engineering)
  • Chooses and applies relevant methodologies where needed and onboards other design/product team members to do so
  • Facilitates design-led collaboration sessions where required.

Key skills:

  • Public speaking, creating slides/strategic and empowering documents, ability to teach/train/convince
  • Stakeholder wrangling
  • Hiring/interviewing
  • Broad knowledge of various techniques across product and design
  • Facilitation
  • People management
  • Design feedback.

UX researcher/product designer

Key responsibilities:

  • Facilitating, organising, documenting, recording and performing user interviews, synthesis, ideation workshops, low-fidelity sketching and wireframing, usability testing
  • Building databases of users for interviews/usability testing
  • Facilitation of internal workshops
  • Works closely with UI designer/engineer and other product team members (including engineers) to ensure continuity of context across any given piece of work
  • Advocates for users and for user-driven design processes; interrogates assumptions; asks why and drives critical risk evaluation across any piece of work.

Key skills:

  • Research design
  • Organising and conducting user interviews
  • Sketching
  • Facilitation
  • Collaborative work
  • Usability testing
  • Wireframing
  • Storyboarding
  • User flow diagramming
  • Synthesis
  • Affinity diagramming.

UI designer/front-end engineer

Key responsibilities:

  • Works closely with UX designer to take low/mid-fidelity wireframes/sketches to higher fidelity (if required for usability testing)
  • Works closely with UX designer and engineers to design high fidelity design components, in code if possible
  • Maintainer of design system, in code if possible
  • Values consistency over artistic flair in order to evolve an efficient design approach through process and patience
  • Eye for detail — checks on work delivered by product team to production; helps maintain a high quality of work; browser and device testing
  • Advocate for and stickler for accessibility across all product deliverables
  • On the cutting edge of front-end and UI best practices and trends, but only applying them where it makes sense given the business case.

Key skills:

  • High fidelity design in Sketch, Figma, XD etc. Familiarity across a range of tooling
  • Ability to create high quality, highly convincing/consistent prototypes in Invision, XD, Axure etc.
  • Front-end dev skills across HTML, CSS, Javascript-based frameworks such as React, Angular, Vue
  • Ability to craft semantic, high quality components to delivery to an existing design system/component library
  • Attention to detail/eye like a hawk
  • Patience and willingness to browser test/device test things even when it sucks
  • Understanding of WCAG A11y requirements and how to apply them for inclusive and accessible design.

How it works in practice

This MVP allows three design professionals of different flavours to deal with three different design needs offered up by almost all organisations:

  • Education, leadership, culture building and stakeholder management
  • Research, validation, usability and assumption-busting
  • Design systems, aesthetics, and kick-ass look and feel

Most importantly, it allows these three core needs to be addressed in parallel rather than in series, which helps each particular “stream” of design work support the other.

One caveat for this — I think this is the MVP for an organisation with one product. For more than one product, I think you need to have a lead, but cells of UX/UI pairs for each product, like so:

Was this helpful?

Was this helpful for you? Do you agree? How does it work at your company? Let me know your thoughts in the comments.

Let’s work together

Are you hiring? Do you need someone to help with this stuff at your organisation? Learn more about me at my website and get in touch.

--

--

Milly Schmidt

Director of product building design research tools at UsabilityHub.