Design Thinking · Management

How do you see your necessity or importance for Design Strategy in your company/products?

Nuno MB Rodrigues

June 1st, 2015

I have heard something that bothered me quite a bit relating to work methods in this case UX methods in projects (web, mobile, business, products) as a "Romantic view of work process" yet this organization way of working is all about "putting out the fires".

What do you think about the importance of Design oriented methods in today's organizations? Important? Important but not so important as to budget? Not important? Just buzz ?


David Schwartz Multi-Platform (Desktop+Mobile) Rapid Prototyping + Dev, Tool Dev

June 4th, 2015

It's hard for me to know how to respond to this. You're kind of asking for what amounts to an entire week-long class in something like Agile development processes.

Also, having been in this field for 35+ years, it's mildly annoying to see terms with long-accepted definitions being swapped for other terms with long-accepted definitions.

Software has always faced the same problem: software engineers sit in a room and are told to solve a technical problem from some set of requirements. If they're really lucky, the people explaining what they want are actual customers. But most of the time they're people called "analysts" who've spent time interviewing potential users, or even worse, guys called "Marketers" who've been piecing together a requirements spec based on things they've learned from visiting customers. 

Nobody ever builds a prototype and shows it to potential users. Management doesn't think that's a valuable use of resources. Even after they've spent 18 months and a million dollars on "V1.0" that right out of the chute doesn't jive with what users want. They'd have figured that out in two months if they'd built a prototype first!

The Lean Startup goes through all of this. Forget what you call the people who do it: Analysts, Designers, Developers, whatever. You need to get customers / potential users involved from the outset. That should include both experienced people (often called Subject Matter Experts or SMEs) as well as newer less-experienced users. Because the people with lots of experience have probably gotten used to all of the hoops they have to jump through, have forgotten about them, and will very likely end up directing you to implement them all over again! The newbies will ask the dumb questions about pain points that the SMEs have forgotten about.

But the worst people in the world to design an app for a vertical market outside of the software world (which is about 99.99% of all software being built) are the people actually building the software! Not only are they terribly myopic, chances are they have little to zero experience in the application domain (regardless if they've built similar software before), and they tend to be heavily left-brained thinkers and have difficulty dealing with anything at an abstract level beyond what they know about basic abstractions related to computer science.

Agile development is two processes: one for management to follow, and one for developers to follow. It's designed to get the two in sync on a regular basis, and let them free-wheel within their respective areas otherwise. One of the participants that's required to be on the team is a customer rep. Unfortunately, this is often someone from management in the software company who's got domain expertise, which, in my experience, is a mediocre stand-in for actual customers and end-users.

What Agile does is create 2- to 3-week cycles, called "sprints", where work goals are established, implemented, then reviewed by not just the team, but management, investors, customers, and any other stakeholders who are interested. When things start to go sideways, you find out at the end of the sprint, not 18 months down the road.

To sum it up, you seem to be trying to characterize this as an issue for people with particular roles. That's simply putting a new face on an old trick (it's what has been going on for 50 years).

What's needed is a fundamentally different approach to the overall product development process. Agile is one approach that has been proven successful -- but mainly when a company bites the bullet and actually embraces it wholeheartedly. You cannot pick and choose pieces then say you're following Agile processes, like, "Oh, we do daily stand-up meetings, so we're now an Agile shop." uh, no.

You need to implement both management-side AND developer-side processes. Too many shops think they can do one or the other; it does not work.

Please note that I'm not advocating Agile specifically, although it's a great approach. What I'm saying is, you need to embrace a PROCESS that's CUSTOMER-CENTRIC rather than developer-centric. Such a process MUST involve the customers from day-one, get regular feedback from them as the product evolves, and management can't be afraid to pivot when it's clear things are going the wrong way -- which happens from time to time normally because it's very common that customers don't know what they want until they see something they DON'T want.

Constantly be testing for product-market fit! Don't rely on your developers to just take a vague design spec and turn out something useful 12-18 months later. It very rarely succeeds.


June 1st, 2015

I think design is vitally important, and that good customer identification and UX building have more leverage to improve a company's trajectory than a good dev team.  But given that, I'm baffled by companies that try to do one-time engagements with design firms or deal with designers as something you can contract out.  I want to work with a UX-specialist whose a full cofounder, with as much skin in the game as me.

Thomas Sutrina Inventor at Retired Pursue Personal interrests and family

June 2nd, 2015

The lack of detail make it very hard to say anything.  No mention of the type of equipment the size or the software goal. NOTHING!

Nuno MB Rodrigues

June 2nd, 2015

Hi Glen, that's because the model of consultancy nowadays doesn't work anymore. That kind of consultancy is outdated. Organizations need to integrate a Design culture in it's core.

When i say Design i don't mean visuals, i mean methods and process. Empathy for the user/public.

But i do understand that it's complicated to change one's culture without breaking some "safety" rules.

I think that the great majority doesn't understand this. I needed to understand why.

This is not a specific question, just a rethoric one. I wanted some opinions and visions on the side of the people who think they need Desing or that think that they DON'T need Design.

Thomas, i'm a bit lost at to what you are asking... sorry.

David MCITP Consulting CTO/CIO for Small Businesses

June 2nd, 2015

I once turned an IBM software development lab on its head by simply streamlining the objectives-setting process.  Ultimately, we were all responsible to the Country VP, a pretty significant guy in IBM.  His motivation was simple:  the company gave him substantial resources:  2,000 software developers in our case, and expected product sales sufficient to support all of us, the sales and support channel, corporate overhead and the shareholders,  Not complicated.  Each product group defined product goals but they usually didn't understand.  So I found a simple way of quantifying the goals in terms of headcount spent, delivery date, and time sensitivity.  There was zero misunderstanding of the goal, "down to the floor sweeper", if you'll pardon the phrase.  There were also zero surprises when our team presented monthly to the VP.  Each project was either on track, at risk of going off the rails without clearly specified corrective action ("the ask"), or broken.  The guy with the authority allocated continued resources and rewards to the "on-track" teams, decided whether to fund the corrective action, accept a different outcome, or stop investing in the "at risk" projects, and whether to terminate "broken" projects or ask for a new proposal.  It took less than 5 minutes per project each month, and every project had its day in court if necessary.

OK.  Management is about investment and return, nothing else.  Our objectives-setting allowed us to interpret the big bosses motivation into project parameters that everyone understood and agreed.  You will notice that the design objectives and methods were nowhere in the equation.  That's because they belonged to the development team.  Developers never seemed to believe that the big guy didn't care a damn how they did it, or even what they built, so long as it made sense to the technical experts (who were a part of the development team) and ultimately to customers, as reflected in sales. That's right a year or two after the fact you learned if you were right or wrong, and whether you needed to adjust your expectations.  That was essential feedback to the development team, who still decided what needed to be built and adjusted for real world changes as they went.  The big guy didn't load his shotgun if the product flopped, he recognized that his management team needed to better at educating the developers about reasonable market expectations.

It worked brilliantly.  I got to do it because the existing over-managed development process consistently failed to deliver products that were industry-leaders or market winners and weren't paying rent.  When we simplified the decision-making and left project as well as technical decisions to the developers, and gave them responsibility for their work, the whole situation turned around almost over night.

Like the others I don't entirely understand your distinction between developers and designers, but it doesn't matter.  The answer to your question is simple, whoever is responsible for the result (developers?) decides, taking input from anyone appropriate (designers?).

Development 101, hire great people, trust them to do the right thing, then keep training them to do it ever better.  Oh yeah, our VP started sleeping nights. recovered from his ulcers, stopped scouring the halls to find someone to chew out, and adopted MBWA to listen what these really smart guys had to say.

Nuno MB Rodrigues

June 3rd, 2015

Thank you David for your insights.

Ok so you wrote about how you managed to turn a disorganized Dev Lab into a proper functioning one where the decisions are at the hands of the Developers, who are responsible for the work, and not managers who don't know how the process work.

When you say you managed to streamline the process, take some over management out of the equation, you found a way to create method, that IS designing a process, a flow of actions, and (another Design method right there...) collaboration between management and work teams.

That's...plainly sensible! That created a functioning dev team and streamlined work.

Now the other side of the coin.

I have worked extensively with Dev teams and learned a bit of their "language", and working closely to managers and CEO's, etc a bit of the "business" language.

Usually in IT Companies decision making is always done by engineers, managers are engineers and what engineers focus around are technical aspects, funcionalities. That usually results in software, apps and products and business solution that are solely focused on the requested features by the client.

It happens that regular users have mental models of what a software or service or product should do and most of the time it doesn't correspond to the software devised by engineers. That's why it happens often that IT companies spend years creating a software they think will work and after those years of work they just find out that the users or audience simply doesn't use it or understands it.

Enter Design methods.

Designers view the world in a different lens and their main concern are people, users, public, audience. They empathically try to figure out their mental models and want to create ways for those users to feel the need for the software.

They usually (in collaborative work) work with IT and other organizations (or at least they should) so they focus on making sense of the product, with business objectives, goals, Human centered aproaches so that piece of software corresponds to users mental models.

I''l give an example: When you pull the break on a moving car, there are a lot of rods, leavers, electric systems working so the breaks eventually press against the disc in the wheel of a car and stop that wheel. Engineers see this whole flow. But in the users mind, their mental model is simply this "i'm pulling a leaver so this leaver is connected to the wheel and stops the wheel.

That happens in software. Software engineers create products based on their capabilities, you can save, copy, and have all the functionalities at hand in the screen, maybe it automatically saves everytime an operation is done... but maybe users just want a clear button that says "save work".

That's just an example of what happens in the IT world. Where companies miss the mark entirely because they disregard Humans as the center of all.

Design helps there. It should be a collaborative work.

David MCITP Consulting CTO/CIO for Small Businesses

June 4th, 2015

Thanks Nuno, now I understand precisely what you mean by designer vs. software engineers.  And absolutely it has to be collaborative.  Both are members of the project team, and if an issue is important, any team member has the right to stand on the tracks.  On a functioning team, dissent is welcomed and should be rewarded, in fact.  It's up to the whole team to become better at what they do over time.

It sounds to me like you're a designer, and frustrated at being ignored by Software Engineers.  Maybe you just don't have a multi-function development team, and there are department walls in the way.  I had cases like that at IBM and I had to bang a few heads.  Because I was reporting purely on the project, directly to "God", I didn't worry about the politics.


But if you're a member of the team,you are responsible for being heard. and be collaborative in reaching consensus.  In the scenario I described at IBM, a risk to market performance was as big an issue as cost or schedule, probably bigger, in fact. It is up to the whole team to deliver a quality product within the constraints given.  The Software Engineers actually build the thing of course, so they have ultimate the power to do it any way they want, but they do not have the authority.  The team will be judged after the fact by the product's success.  Ultimately that will determine who does and does not get team leadership positions down the road.

So in my situation at IBM, the team's monthly report could include a concern from the designer that the product would not reach its business goals with the UI imagined by the Engineers.  That report goes directly to the big boss at the top of the food chain, so you better have some evidence of your claim.  The real issue is that the team does not have consensus, and needs to evaluate the impact of each alternative.  So before you go blowing the whistle, you raise a project issue that you need to evaluate the UI before implementing it.  Usability tests, focus groups, field trial or whatever makes sense.  If the group is functioning properly, they recommend to the big boss that the project be changed to incorporate the tests.  The recommendation comes with the additional funding, headcount, and time required. to do the tests.  Now you're running it like a business.  Now the big boss can make a simple decision.  Can he afford this or not?  Does he think it's worth it or not?  If yes, everyone is happy, and you go with whatever results you get from the user tests.   And the project expectations have officially agreed and changed.  

In this case the boss will say yes 99% of the time, and congratulate the team for its professionalism.  But sometimes he'll say no.  It's his business after all, and there may be factors you know nothing about.  But if he says no, you've been heard, and the risk is now on him.  If it actually flops for the reason the team had predicted, the boss is on the hook, in writing.  Both the team and the boss will make better decisions on the next project.

So I guess that the answer to your original question is that there is only one project team, it has all of the necessary skills represented, and it must achieve consensus. "Because I know better" is not an acceptable response from anyone. The choices are simple, go one way, go the other way, or get more information. In our example above, it would be pretty hard for the Engineers to refuse to even ask permission to find out.  In that case, I might write the report that the project is at risk because the team is not in consensus.  What I would say would not be as polite as what I wrote on the record, even though I am an Engineer.

I always write too much, but I hope that makes sense.





David MCITP Consulting CTO/CIO for Small Businesses

June 5th, 2015

David Schwarz,

Good Reply.  Could you please explain who is involved as "Management" and their role in the development process.  From a traditional point of view, Managers exist to authorize resources and approve/deny project changes, as well as administrative functions like salaries, promotions, professional development, budgets, infrastructure, and so on,  so if they are involved in product development everyday, Agile must mean something different.  How does that work?