The rise of the design rock star, the full-stack developer, and various other unicorn breeds, along with the move to make everyone a coder, has made the creation of digital products too focused on metrics—and not enough on quality.
Designing Products, Not Pixels
Companies increasingly pursue design with great vigor and much discussion, but in many ways, with increasingly poor results. The UX design community spends a lot of time arguing which screen-design tool is best and talk about screen-design workflow with a straight face, while most junior designers have never actually designed an information architecture.
Champion Advertisement
Continue Reading…
We need to get back to collaboration, team work, and product design, acknowledging the following:
Team diversity is good. Not everyone has the same skills, and teams work best when each individual focuses on his or her own practice area.
Products are for users, so user needs must drive all decisions.
There is no gut instinct. Base every decision on logic and science.
Every process should be as efficient as possible, but no faster. Consider the consequences of failure, and make sure the product works right the first time.
We’re creating products, not art, to be reproduced infinitely for the use of thousands or even millions of people over years.
To accomplish all of this, we need to recognize the difference between design and craft—and that process is not a magic pill, but must be designed to suit individual organizations, just as we design the products we make.
Design and Craft
There has long been misunderstanding about what design is. Many perceive design as art—entirely at the whim of the designer. Therefore, they think anyone else’s opinion is as valid as the designer’s, and they can second guess any design decisions or simply change them during execution.
However, design is not art. It may be easiest to discuss the distinction between the fine arts, applied arts, and design.
fine arts—The artist creates works of fine art to be beautiful, communicate an intellectual message, or stimulate conversation on a topic. The way other people perceive fine art is fluid, and there is no incorrect interpretation.
applied arts—The applied arts are decorative. The artist adds decorative features or modifies the methods of manufacture to add beauty or style to an existing product that already works properly.
design—In contrast to the arts, design is the creation of a solution to a problem. Whether a designer is creating an illustration of a concept, a chart, functional furniture, or a digital product, a successful design improves upon existing solutions or solves a problem that no one has yet adequately addressed. It can be beautiful, but that is not its purpose.
Before the industrial era, these distinctions were much less clear because most goods were manufactured by individuals or in very small shops run by master craftsmen. Such craftsmen would create a design or reuse one passed down from his mentor or ancestors and execute the design with only minor variations—or possibly, by applying decoration—but they rarely innovated wholly new designs. Apprentices faithfully executed these designs without adding their own creative style.
This still happens today in some artistic industries. Skilled craftsmen manufacture handmade goods such as fine-art prints or pottery, but they do not imbue the work with their own sensibility or style.
Design and Production
In the industrial era, machines and processes enforced manufacturers’ executing the original design, so unskilled workers could create the same item over and over. Ultimately, this led to the rise of the design and engineering disciplines. No longer did goods have a style. Nor were they regionally similar. Now, products had a design phase, during which a product was specified or modified for manufacturing, then the manufacturer created many identical copies of the product. Suddenly, people stopped creating or buying objects. They bought products. Over time, we’ve discovered that unskilled workers do not produce the best results. It is better to find skilled workers or train them and give them roles in which they enjoy the work they do.
Design has evolved beyond graphic design or user-interface design to include software design, process design, and so on. To create good products and allow consistent, high-quality manufacturing to work properly, everything must be designed.
Manufacturing Digital Products
In many ways, digital product design has not evolved past the craftsman in the shed era. We’re acting as though the industrial revolution never happened and have added processes to improve the way traditional, small craft shops operate. We carry on traditions and do whatever the master craftsman thinks is a good solution to the problem at hand.
Here and there, digital product development does use modern, industrial methods. Often, hardware, firmware, and some embedded software uses rigorous design methods to ensure effective design, manufacturability, maintainability, and sustainability.
We can expand on these methods to improve the design of all digital products, including Web sites and mobile apps. Fundamentally, we must do the following:
Design products that provide value both to the organization and to users.
Use consistent, sustainable methods.
Employ the skills—the craft—of each team and team member for the best and most efficient design and production.
This means everyone works together, focusing on their area of expertise. It’s important that developers not argue about the user-interface (UI) design and product managers not insist on specific database schemas. On diverse product-development teams, a key approach is gaining the efficiency of assembly lines. Second guessing or duplicating work removes that efficiency. Let everyone do what they are good at.
Existing methodologies such as Lean and agile—especially Scrum—can solve only the manufacturing part of the problem. We don’t need improved development methodologies or even better design processes in isolation, but a complete, end-to-end way of conceiving of, designing, and manufacturing digital products.
A Digital Product–Design Process
I have been involved in product design, mostly in digital spaces, since the mid-1990s. I’ve been a developer, a database administrator, a system administrator, a usability researcher, a graphic designer, an ethnographer, a UI designer, an interaction designer, and a manager of teams who do all this and more.
Over the years, I have driven many product-design processes, and I’ve increasingly been expanding my methods from design, to design and development, to what I’ll describe next: the end-to-end, digital product–design process I’ve outlined in Figure 1. I have previously written about many of these individual topics, and there are many ways to get to a good result at each step of the process, so I’ll discuss each one fairly briefly.
Figure 1—A simplified depiction of the digital product–design process
Ecosystem Design
Almost every project comes to me with enormous specificity: It will be an app for iPhone and will mainly do this one thing. Or we’ll migrate a successful legacy product word for word, and it will have buttons for specific functions. But the first job of a UX designer is to reject anyone’s dictating design solutions at this stage outright. It’s way, way too early to be that specific.
Learn the Domain
First, you must learn the domain so you can speak the language of the product and the team building the new product. Learn about the industry, the specific role the product performs, legacy products, the competition, and existing products that fill the need, however poorly.
Get a good, truthful understanding of who uses the product and what they really need. Existing feedback channels from sales and marketing, trade shows, and training often give a skewed, too high-level response. Get into the field and observe real people who need the product if you can.
What to Build and What Not to Build
Find out whether the product idea has value. Do ideation workshops with the product team and perform ethnographic studies—or even usability studies on existing products. Consider much of the output from this analysis as a post mortem, or as I prefer, an after-action review. Identify what features to keep and, specifically, what to not create this time around.
Often, quite specific ideas will emerge from this process, but rarely the final UI widgets. It’s usually more about setting up proper data structures and defining parts of the hierarchy or information architecture.
Strategic, Not Tactical
Don’t start by designing a specific product, but by considering the entire end-to-end user experience. Don’t compete with other things your organization makes, and don’t limit yourself to pre-existing technology choices. Maybe the best solution would be a sticker, better shipping methods, or hiring new employees for the store, not a mobile app or Web site.
Outputs of Ecosystem Development
audience
existing solutions or competing products
goals and objectives of the organization
users’ needs
success measures
likely platforms, data needs, data architectures
good ideas, bad ideas
strategic positioning
Concept Design
Concept Design allows us to bring the high level to the tactical, as quickly as possible. I usually sketch out task flows and draw a few key screens or variations on screens. This enables everyone—even those who do not visualize ideas well—to get their head around the proposed design and gives senior managers something pretty to put in PowerPoint status presentations.
Remaining at a high level makes it easy to quickly iterate the design without time delays. The design looks unfinished so no one feels they cannot contribute, and it has cost little time and money to create it, so the team won’t stick with bad ideas because of a sunk-cost bias.
Creating a complete, end-to-end Concept Design is not just a UX designer’s task. Whenever possible, I engage Engineering—software, database, API, or firmware—Product, Industrial Design, Legal, and everyone else in creating and validating the concept.
Validate the Concept
In an ideal world, you should test the concept with actual users. This is not a time to share your work with a design group on LinkedIn, run a survey, or get feedback from demos. Employ good user research methods to determine whether you’ve got the right product concept to meet users’ needs. Refer back to the measures of success you created earlier.
Prototype if you must—but only if you must and only as much as you need to. The goal is never to make a prototype, but to find the right design direction and bring the team into alignment. If a whiteboard sketch, paper prototype, or bulleted list is enough to represent a design concept, there’s no need to do more.
When a Concept Fails
If the results of concept testing are poor, start over. Either try a new concept or go all the way back to the beginning and have the team consider the test results as new input. Never consider failure a personal or procedural mistake, but a learning experience that provides valid data you can use to create a better product.
Output of Concept Design
high-level task flow
high-level data architecture for service design
conceptual UI and interaction design
proposed software design
Operational Planning
It is now time to nail down everything else. Everything. Make sure there are no open questions about the product. Make sure Marketing has a plan to support the product, that it meets the requirements for security and legal approvals, and so on. (I’ve worked for a year on a product that never launched because of legal issues.)
This is also the last effective time to decide who belongs on the project team and who else you need to coordinate with. For example, when you launch, your Customer Service organization has to be able to support the product. They won’t be able to do that well if you notify them just ten days before launch. Involve them—and anyone else who needs to know about the product—early on.
Target Scope of Work
About midway through creating Concept Design deliverables, I generally start getting people on the project team who are confused about why we’re planning product features beyond the first release. While there may be other good design reasons, I usually explain to them that it is all about eliminating technical and UX debt. If a project team needs to make short-term, throwaway decisions, that’s fine—but only if you make them consciously and deliberately. To ensure you do that, you need to aim for a particular target.
So, around now, start making explicit plans and creating the target design. Create stories for the backlog—not just for the first release, but for whatever future you envision. For some projects, that’s five or ten years out, but for most, it’s more like 18 months.
What should you include in the target scope of work?
features
information architecture or task flow
data model
plan or design for APIs, services, and data storage
identity management, access control, and security
domains, platforms, frameworks, and technical methods
scale and other targets or goals that can inform additional technical decisions
This work is actually core to a lot of modern development methodologies such as agile, although people rarely talk about this work explicitly.
The backlog is everything. You’ll know what all will be in Release 1 only once you’ve done the exercise of putting everything in the backlog, prioritizing, and designing or scoping the solution.
Plan and Prepare, Technically and Operationally
In addition to making decisions on how to build the product, it is now time to prepare to build it. Make sure that everyone has installed the necessary software and systems. If you are so lucky to have them, make sure that there is a shared workspace for all members of the project team. Make sure that the Internet works everywhere, there are plenty of spare whiteboard markers, and conference bridge numbers work.
Team leaders must have their standards in place—from design style guides to code practices—so product work that you do in six months meshes seamlessly with the work you do initially.
Plan for the end state now. Sure, sometimes it is important to plan for a product’s end of life. But initially, you must at least plan how you’ll actually launch the product. Do you own a good domain name? Are servers set up? Do you have Play Store and AppStore accounts? (I’ve been on Web projects for which contractors had to be hired to create trenches in which to lay fiber between data centers.) Get all of your advance planning done now. Of course, you will iterate on the product design as you go forward, but not on the methods that will get you there.
Output of Operational Planning
final project team
people and teams with whom to coordinate
style guides, brand standards, code standards, and testing methods
complete logistics, installations, environments
plans for release and launch tasks
Sustainable Design
“The crafts exist to promote lasting value, increasing the meaning and physical quality of objects.”—Gareth Williams
Sustainability is primarily about reducing waste. For digital products, waste results from inefficient code, excessively large file sizes, and data transfers that use too much power and require extra storage capacity.
But mostly, sustainability refers to the ability to sustain a product’s longevity, reliability, flexibility, and maintainability. This means not launching with hacks or any known technical or UX debt, so you can keep the product operating for a long time with minimal effort. Version 2.0 should never have to be a clean-sheet design. That’s wasteful.
Sustainability could be a goal or sub-task of the Operational Plan. However, on many projects, teams are given too little notice for these tasks, or they forget these tasks as the project proceeds, so I’ve broken them out separately here.
Standards and Reusable Components
A great way of making the design and development of digital products more efficient is to employ reusable components. But, to do this, the design team needs a style guide, and development needs to use object-oriented methods. Rarely will you have the time and budget to do this work up front, but if you’ve been following the previous steps, you’ve already been working on some of this—or perhaps you can sneak in the work, so it becomes easy to do. If not, plan to build each feature modularly, then turn these modules into a library of components. This can work just fine, but it does take planning.
Success Measures
Go back to your initial project work and look at the goals and objectives. Decide how to measure success—both the actual measures and the measurement methods. I’ll discuss test and measurement practices a bit later.
Output of Sustainability Planning
planning for efficient design
design standards, style guide, communication standards, and brand standards
planning for component development
final goals, objectives, and success measures
test planning, scheduling, and logistics
choosing and installing analytics tools
scheduling customer input and communications
planning for the product’s end of life
Production Design
Once planning is complete, it is time to manufacture the product. Incremental, iterative processes have ruled for decades—even before agile came on the scene—so let’s assume your project will use such a process. You’ll develop a little bit of the product, then a little more, and so on until it’s finished. So far, your design work has been at a high level—although you may have done detailed planning for component reuse. Now, you need production-level designs for the first few sets of features to be developed.
Ongoing Concept Design
You must continue evolving your concept design. I’m not talking about design in code here, where there’s no real design step at all. Even at this level, once designers create a detailed design solution, they must discuss it with the project team, then advance it to manufacturing.
Analyze and Specify
Designing screens is often like a craftsman’s carving chair legs by hand, but it shouldn’t be. To me, this is the difference between user-interface (UI) design and UX design. Don’t draw pixel-perfect screens at each resolution. Instead, specify the product or feature design. I also draw, but the specification is the key. Design by following principles and patterns and extend the specification cascade down one more level. Recall that you’re using systems of design patterns, styles, and reusable components. By thinking systematically, you can create a great product that meets users’ needs, instead of making just a single screen beautiful in isolation from the whole system.
In agile processes, this step is where you should start working one sprint ahead. It is not start-from-zero design, but finalizing the vetted design, following principles and patterns, after you’ve gotten answers to all your questions so what you’re building is clear.
Output of Production Design
feature details, in the form of user stories or some other guide for development
technical specifications
UX specifications
test plans and test criteria for each feature
Production Engineering
Manufacturing a product you’ve planned and designed may sometimes involve the manufacturing of circuit boards or other hardware. But, for digital-product designers, manufacturing is always about building code that is suitable for release to your customers.
Remember what you’ve learned from manufacturing in big factories: unskilled workers create mediocre products. Don’t hire interns or developers from the lowest-cost, overseas vendor, working without oversight. Even development using a framework requires good development skills. Let your developers practice their craft so they can build better solutions for your product.
Proof of Concept
Iterative design allows iteration—attempt, improvement, revision—at each step. Just because someone has said a feature is to be in the next release doesn’t mean it can actually be done. Anything that the team is unsure about should be explored and tested before committing it to the final code.
Of course, this is true of any design—from technical solutions to UI designs. Validation may mean anything from determining whether it’s possible to code an idea at all to putting a prototype of an idea in front of users. Either way, it takes time for Engineering to build proofs of concept. You must account for this during planning. Never consider the time you spend on proofs of concept wasted time.
Production Code
Code is not the end-all or be-all of our work. But it is necessary to make a product real. In the common analogy in which the UX designer is the architect of a house, developers are the builders. And just as there are earthmovers, concrete guys, framers, plumbers, electricians, roofers, drywallers, and more construction workers who contribute to building a house, there are many kinds of coders. Building Web applications means not just HTML and JavaScript, but the API, the database behind that, and perhaps much more. For example, I’ve worked on industrial IoT products for which we had different development groups for the Bluetooth layer, the software for the data adapter, and the machine to which it connects as well.
Iterations scale. Individual developers need time not just to bash out the first quick chunk of code, but to explore better implementation ideas, fix problems, and talk ideas over with the team. Speed is good, but never confuse speed with quality. Try not to make speed a measure of success in itself. Give developers time to complete high-quality work.
On the other hand, true iterative development means there is no such thing as final code, or being code complete. Choose a point at which you’ve met the feature requirements and the test results are good enough. But in the next iteration, you might blow it all up again to create the next set of features. Agile methods are fundamentally what is called test-driven development. You can tell the code is complete only when you’ve looked at it to make sure it’s right.
Output of Production Engineering
functioning code ready for test and release
all code on which you need to build in the next iteration
Test, Validate, and Fix
The people writing checks for all this work need to be able to prove to their boss that it was worth it, so empower them—and preserve all your jobs—by actually following up on those success measures. Do this regularly. Plan to track use, install analytics, and get a vendor to run user-satisfaction surveys. Annual reports aren’t enough, but quarterly reports may be. Some organizations want weekly or even daily reports. You need to set expectations up front.
Companies often give technical testing short shrift or assume that simply hiring a team will cover it. Test teams need their own test environments and must understand what to test. Their work needs to be on the schedule—and don’t steal their time if development falls behind. Do not rely on unit testing or eyeballing screens. Have a robust plan for checking that the system is working properly, has good performance, and has been built as designed.
Check the Work
Every team should be required to validate whether the built product meets all specifications and requirements. A lot of work went into design and planning, so any gaps are not just mistakes. If code deviates from plans, these gaps will compound over time. Agile demos are a good starting point for validation. Test sessions for reviewing specific functions are critical. Make sure that no voice gets lost and all feedback makes it into the final product.
Fix the Problems
Here’s one of those points at which old-school business pressures often ruin products. If it’s important that something launch on time, you may be asked to just go ahead and release buggy or ugly software. Don’t do it! Make sure you’ve got a plan to fix everything that needs to get fixed before launch. That plan should be specific, not vague, and follow the same process. Each bug should get its own feature or story and get fixed in turn.
Maybe the team won’t fix everything right away. Sometimes, fixing something is not worth the effort if there will soon be a better feature to replace it. But every issue should ultimately get resolved. Don’t let anything remain flawed forever.
Output of Testing and Iterating
viewable or, preferably, clickable code
a list of every feature that Development thinks ready for review
a report on completeness from every team that wrote design documentation or specifications
Repeat & Revise
Never let your team become complacent and just execute on features without considering the entire development process. You won’t have to redo your plans every time, but do review them periodically. Make sure they still apply, and when changes are necessary, take the time to make them.
For each feature set you’re building during an iteration, be sure to consider the overall goals and objectives, and use research findings and feedback to see whether your audience has changed. Update the task flow with each new feature set.
Recurring Features
A lot of the work you do to keep a product alive means doing the same things over and over, with minor variations—things like updating the documentation for Technical Support, uploading new releases of your app to an online store, simply updating an error table, or doing another round of performance improvement.
Be sure to leverage the methods of your development process in completing these tasks, then do them again whenever necessary. Don’t design, approve, and execute these tasks anew each time. This is another key reason to document your process—so you know what to do and why, and you can better track changes over time without reinventing the wheel for each release.
Designing a Process for Your Organization
For much of my career designing Web sites, apps, and services, engineering-centric processes and methodologies have prevailed. At their best, these resulted in improved user interfaces and cleaner microinteractions.
But this end-to-end, product-design process I’ve outlined is all about solving problems at a higher level—creating a minimal user interface and reducing the number of user and system interactions. Many details of the process I’ve described are deliberately vague because the implementation of those details may vary according to your context. You may find some step unworkable in your organization or discover that I’ve missed a whole step that you consider essential. That’s fine. I’ve just described what I ideally do.
The most important thing is that your team should move from working on tasks individually, with occasional collaboration points, to producing products as a team. You need to create your own end-to-end, product-design process that works for your organization. Please share what you’ve already done and how it has gone in the comments.
References
Centers for Disease Control and Prevention. “Product Design.” (PDF) CDC Unified Process Practices Guide, December 31, 2007. Retrieved October 21, 2017.
Greehalgh, Paul. The Persistence of Craft. London: A&C Black, 2002.
Thank you for the insightful post. I can relate as I find design one of the most important stages in the SDLC because the vision of the final product is created here and the thoroughness of design work can help to avoid expensive change applications later.
For his entire 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s publications include Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He runs his own interactive design studio at 4ourth Mobile. Read More
